11 International ACH Transactions and OFAC Scanning
This chapter concludes the iteration by extending a domestic ACH solution to support International ACH Transactions (IAT) and by introducing basic compliance controls through OFAC scanning. It explains why the business needs IAT (cross-border credits/debits) and how that raises regulatory risk, requiring safeguards to avoid transactions involving sanctioned people or jurisdictions. The narrative frames the work as a sprint: define scope, plan tasks, and deliver an end-to-end slice that creates, parses, stores, and displays IAT data while keeping the existing PPD flow intact.
On the implementation side, the project updates file creation and parsing to respect the SEC code and IAT’s constraints, including the 94-character record limit and mandatory addenda (710–716). The database gains new IAT-specific header, entry, and addenda tables while preserving the parsed/unparsed pattern; special handling is added for delimited fields embedded in fixed-width records (for example, the 712 addenda with city/state/country/postal). The parsing pipeline is driven by unit tests, schemas, and SQL helpers, and the file processor branches on batch_type (IAT vs PPD) to route records and enforce addenda order. The dashboard and APIs are adapted to surface mixed files, using joins and COALESCE for batch lists and a dedicated query for IAT entry details, keeping PPD behavior stable.
The chapter then implements a minimal OFAC scan: seed placeholder SDN and sanctioned-country tables, collect individual names from both PPD and IAT (IAT from addenda), and apply fuzzy matching via Postgres’ fuzzystrmatch (Levenshtein-based similarity plus Daitch–Mokotoff phonetics). Results are combined and filtered, exposed through a new API, and rendered in a UI grid with match scores and navigation back to the related file/batch. It closes with production considerations: run scans at ingest and periodically, persist auditable results, address scale and performance, reduce false positives with more context (aliases, addresses), and offload heavy work asynchronously to maintain responsiveness.
Timeline for IAT ACH Transaction processing
Sample IAT Batch
Routing Number and Account
IAT Batch Header
IAT Entry Record
Sample OFAC Report Screen
Summary
International ACH Transactions (IAT) introduce unique regulatory requirements and require precise formatting, underscoring the need for careful planning and compliance verification in financial systems.
Expanding database structures to accommodate IAT involves integrating new tables tailored for specific ACH components, reinforcing the importance of planning for system scalability.
Generating IAT batches requires adapting current solutions to handle additional header and entry information, highlighting the complexity of international transaction standards.
Comprehensive unit testing ensures new IAT functionalities align with existing PPD processes while preventing disruptions, showcasing the importance of regression testing in software development.
Streamlining code through refactoring enhances maintainability and reduces redundancy, indicating the continual need for codebase optimization as projects evolve.
Integrating IAT processing in dashboards requires understanding both technical constraints and user needs, emphasizing cross-functional alignment in feature development.
Designing APIs to handle IAT data ensures consistent data retrieval and processing, demonstrating the necessity for flexible yet robust system interfaces.
OFAC compliance is crucial when processing IAT to mitigate risks associated with sanctioned individuals, highlighting the role of regulatory adherence in transaction processing.
Implementing fuzzy matching algorithms aids in detecting minor variations in suspect names, thus increasing accuracy in identifying sanctioned transactions.
Effective UI components for OFAC results delivery underscore the value of clear, actionable insights for users navigating complex compliance landscapes.
Persisting scan results addresses compliance demands by providing traceable audit trails, stressing the need for reliable data storage and retrieval in financial applications.
The addition of IAT processing elevates organizational risk awareness, underscoring the critical need for stringent compliance frameworks to navigate international regulations effectively.
FAQ
What is an International ACH Transaction (IAT) batch, and how does it differ from a PPD batch?IAT batches enable electronic transfers between accounts in different countries. They still conform to the 94-character ACH record limit but differ from PPD (domestic) batches by requiring 7–12 addenda per entry (with seven mandatory addenda 710–716). IAT entries always include addenda, and certain data (like receiver name) moves to addenda rather than the entry record.Which mandatory IAT addenda records are required and what do they capture?The seven mandatory IAT addenda types are:
- 710: Foreign payment amount and receiver’s name
- 711: Originator’s name and street
- 712: Originator’s city, state/province, country, postal code
- 713: ODFI name, ID, and branch
- 714: RDFI name, ID, and branch
- 715: Receiver’s ID number and street
- 716: Receiver’s city, state/province, country, postal codeWhy are database changes needed for IAT, and what tables are added?IAT introduces a different batch header, entry fields, and multiple mandatory addenda that aren’t present in PPD. To store parsed IAT details, the chapter adds at least nine tables (IAT batch headers, IAT entry details, and one table per each required addenda type). Unparsed record tables remain unchanged because record types (1,5,6,7,8,9) still apply.How does the chapter handle the unusual “delimited-in-fixed-length” IAT addenda fields?Some IAT addenda (for example, type 712) embed multiple data elements within fixed-length fields, delimited by an asterisk (*) and terminated by a backslash (\). The parser extracts these elements (e.g., originator city and state from a 35-character segment) using regex and stores each in separate columns, preserving max lengths to avoid confusion.How is file creation updated to support IAT batches?File creation is updated to respect the SEC code “IAT” in the batch header (e.g., foreign exchange indicators, ISO currency codes). Entry building for IAT always includes the correct number of addenda. The code paths branch on the SEC code so IAT-specific batch header and entry/addenda blocks are emitted correctly.How is the ACH file processor adapted to parse both PPD and IAT?Processing now sets a batch_type flag after reading the batch header (PPD or IAT) and routes to corresponding parsers. It maintains expected_record_types to enforce sequence and introduces expected_addenda_type to verify mandatory IAT addenda order (710→711→…→716). On completing 716, expectations reset so the next record can be a new entry, addenda, or batch control.What unit testing approach ensures IAT support doesn’t break PPD?The chapter adds regression tests for PPD (counts of unparsed and parsed records) and parallel tests for IAT that verify presence of all IAT detail tables (batch headers, entries, addenda 710–716). Tests exercise parsing logic, database inserts, and error handling (unexpected SEC or addenda types) to validate sequencing and data integrity.How do IAT changes impact the dashboard and APIs?- Batches endpoint: Uses COALESCE across PPD and IAT batch header tables to unify results without breaking existing consumers.
- Entries endpoint: Splits logic into _get_ppd_entries and _get_iat_entries, selecting the right query based on whether a batch is IAT. For IAT, addenda-derived fields (like receiving_name) are joined from addenda 710; addenda counts are computed to allow verification.What is OFAC scanning and how is it implemented here?OFAC enforces sanctions via lists (e.g., the SDN list) of individuals, entities, and countries. The chapter builds a basic scanner that:
- Stores mock SDN names/aliases and sanctioned countries
- Collects individual names from PPD (entry detail) and IAT (addenda 710)
- Uses Postgres fuzzystrmatch for Levenshtein similarity and Daitch–Mokotoff phonetic matching
- Flags matches via a threshold (e.g., similarity ≥ 80) or phonetic matches
- Exposes results via an API and displays them in the UIWhat production considerations apply to OFAC scanning and IAT processing?- Performance: On-demand scans don’t scale; run scans at file-load time, cache results, and store audit copies for compliance.
- Auditability: Persist results with timestamps to prove historical matches even as lists change.
- Asynchrony: Large files and fuzzy matching benefit from background jobs and file-level processing status.
- Accuracy: Incorporate more attributes (address, DOB, IDs) and commercial matching algorithms to reduce false positives.
pro $24.99 per month
access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
Build Financial Software with Generative AI (From Scratch) ebook for free
