Compliance by design: building OFAC screening, 314(a), and audit trails into the product
Compliance work that lives in spreadsheets and inboxes doesn't scale. Here's how we design screening, investigations, and audit trails as part of the product itself.
Oct 26, 2026 · 3 min read
In most banks and fintech programs, compliance is a daily workflow, not a quarterly event. Analysts clear sanctions hits, work fraud alerts, answer law-enforcement information requests, and document every decision. When the software doesn't support that work, it moves into spreadsheets and email, which is exactly where auditors don't want to find it.
Here are the patterns we use to make compliance part of the product.
Sanctions screening (OFAC) at every entry point
US institutions must not do business with people and entities on OFAC's sanctions lists, including the Specially Designated Nationals (SDN) list. In software terms, that means screening customers, counterparties, and payments, at onboarding and again when lists change.
What good looks like:
- Screening runs automatically on customer creation, counterparty creation, and payment initiation.
- Potential matches go to a review queue instead of blocking silently or passing silently.
- Every disposition records who cleared the hit, why, and against which list version.
- Screening status is visible directly on the customer, counterparty, and transaction screens.
Fuzzy name matching produces false positives. That's expected. The goal is to make clearing them fast and well documented, not to tune the matcher until it misses real hits.
314(a) requests as a searchable workflow
Under section 314(a) of the USA PATRIOT Act, FinCEN periodically sends financial institutions lists of subjects that law enforcement is investigating. Institutions search their records and report matches within a fixed deadline.
Done by hand, this is a recurring fire drill. Built into the product, it becomes routine:
- Ingest each request list as a dated, versioned record.
- Search across customers, accounts, and transactions in one step.
- Track each request's status and deadline on a dashboard.
- Keep the evidence of the search, including what was searched and when, even when there are no matches.
Fraud and AML alerts in one queue
Fraud teams and BSA/AML teams often work the same customers from different tools. We prefer one alert and case model: alerts from velocity limits, screening, and monitoring rules land in a shared queue, can be escalated into cases, and carry a full timeline of notes, decisions, and attachments.
That gives investigators a complete picture and gives the compliance officer one place to answer "what did we know, and what did we do about it?"
Audit trails that are actually useful
Every serious financial system claims to have an audit log. The useful ones share a few properties:
- Append-only. Entries are never edited or deleted; corrections are new entries.
- Human-readable. "Velocity limit raised from $5,000 to $10,000 by J. Smith, reason: customer request #1234" beats a JSON diff.
- Attached to the object. The timeline lives on the account, customer, or payment, where an examiner will look for it.
- Complete. Logins, permission changes, configuration changes, and money movement are all recorded.
Controls that let you act fast
Two controls come up in almost every regulated product we build:
- Role-based access with maker / checker approvals for sensitive actions such as limit changes, high-value payments, and account closures.
- Kill switches at the program and product level, so a sponsor bank can stop activity for a single fintech partner instantly without touching anyone else.
If an examiner asked to see why a decision was made, could your product show them in one click? That's the bar.
None of this is exotic engineering. It's mostly a matter of deciding, early, that compliance users are first-class users of the product, with screens, queues, and timelines designed for their work.