The Difference That Matters to Regulators
Let me tell you about a conversation that happens regularly in fintech companies. It usually takes place around month nine of building a lending product, when someone in a leadership meeting asks ‘are we AML compliant?’ and the CTO looks at the Head of Product, who looks at the engineering lead, who opens a browser tab to the third-party compliance vendor’s dashboard and says, with the specific confidence of someone who is not entirely sure, ‘yes, we have the compliance module running.’
The compliance module is running. That part is true. Whether it is running in the right way, at the right point in the transaction lifecycle, capturing the right data, and generating documentation that would hold up under regulatory scrutiny — those are different questions. Questions that tend to get answered either in a calm review meeting when you have time to prepare, or in a very different kind of meeting with someone from a regulatory body who has a list.
The difference between those two outcomes is largely determined by an architecture decision that most fintech teams do not think of as a compliance decision at all. It is a decision about where compliance lives in your stack.
What 'Compliance-Added' Actually Means
Most fintech lending platforms approach compliance the same way. You build the lending infrastructure — origination, servicing, disbursement, repayment. Then you add the compliance layer. You connect to a KYC provider. You integrate an AML monitoring tool. You set up your SAR filing workflow, usually through a combination of the AML tool’s interface and your own internal process documentation.
This approach is logical. It is sequential. It gets you to market. And it creates a specific category of compliance risk that does not show up in your compliance vendor’s dashboard — because that dashboard is only showing you what is happening inside their system.
Here is the problem. When compliance runs as a separate system connected to your lending platform via API, there is always a gap. Not a gap in intent — your compliance team wants to screen every transaction. A gap in timing. A gap in data completeness. A gap in the chain of custody that regulators are looking for when they examine your AML programme.
The Timing Problem
An API call to an AML screening system takes time. A few hundred milliseconds in the best case. Several seconds if the external system is under load. In a well-designed integration, this is handled asynchronously — the transaction moves forward while the screening runs in parallel. That is the engineering-correct solution. It is also the compliance-risky one.
If a transaction is processed before the AML screening completes and returns a result, there is a window — however small — where a flagged transaction could move forward. Your system did not knowingly process a suspicious transaction. But your system processed a transaction before it was screened. Whether that constitutes a BSA compliance failure depends on your written AML programme, your regulator’s interpretation, and how you explain it in the examination.
In a native AML architecture, this window does not exist. The screening runs in the same transaction as the lending event. There is no asynchronous call. No timing gap. The transaction cannot proceed without the compliance check completing — because they are the same operation.
The data completeness problem
External compliance tools receive the data you send them. They do not have visibility into your platform’s full event context unless you have explicitly built the integration to pass that context. In practice, most integrations pass the minimum required data — customer identifier, transaction amount, transaction type. The compliance tool screens against that.
What it does not have, unless you have specifically engineered it, is the full origination context. The loan application details. The KYC result that was returned six weeks ago. The pattern of repayments and drawdowns that preceded this transaction. The relationship between this customer’s behaviour and three other accounts that share an address.
A native AML engine has all of that. Because it is running on the same data model as the lending platform. The screening decision is made with the complete financial history of the customer and the complete context of the transaction — not just the fields that were passed in an API call.
What Regulators Actually Look For
The Bank Secrecy Act requirements for an AML programme have not fundamentally changed in decades, but the way regulators examine them has become considerably more sophisticated. An examiner today is not just looking at whether you have a compliance vendor. They are looking at whether your compliance programme actually functions the way you say it does.
There are three things that consistently distinguish a compliant AML programme from one that looks compliant in documents but has gaps in practice.
The audit trail is complete and contemporaneous
Contemporaneous means the record was created at the time of the event, not assembled afterwards. A compliance programme that generates audit trail documentation by pulling records from multiple systems and reconciling them after the fact is vulnerable to the question: ‘How do you know this reconstruction is accurate?’ A native AML architecture where every compliance event is recorded in the same system as every lending event generates a contemporaneous audit trail by default. It is complete because it was never fragmented.
Screening runs against current data
Sanctions lists change. OFAC updates the SDN list regularly. New PEPs are added. Existing entries are modified. An external AML tool typically receives list updates on a schedule — daily, weekly, or in real time depending on the provider tier you are paying for. A compliance programme that screens transactions against a list that was last updated 36 hours ago is technically running screening. Whether it meets your written AML programme’s requirements depends on what that programme says — but ‘we screen against the most current available data’ is a harder statement to make if your list updates are managed by a vendor on their schedule rather than your own.
Exception handling is documented and traceable
What happens when a transaction is flagged? In a compliance-added model, the flag appears in the AML tool’s dashboard. The compliance team investigates. They make a decision. They document it — in the AML tool, in an email, in a spreadsheet, in a combination of all three depending on the maturity of the programme. The chain of custody runs across multiple systems, and the documentation of the investigation decision may or may not be linked clearly to the original transaction record in the lending platform.
Regulators want to see: transaction flagged, investigation opened, decision made, decision documented, outcome recorded. In one place. Traceable from the transaction to the resolution. That is straightforward in a native compliance architecture. It requires careful process design and usually some custom engineering in a compliance-added model.
Here is a realistic timeline for a fintech team building a US lending product from a five-vendor stack. These numbers are drawn from patterns observed across real deployments, not invented for effect.
The most common compliance failure is not the absence of a compliance programme. It is a compliance programme that runs alongside the lending operation instead of inside it.
The BNP Paribas Problem — and Why It Is Not Just a Big Bank Issue
BNP Paribas. $8.9 billion fine. HSBC. $1.92 billion. TD Bank. $3 billion in 2024.
These numbers are cited in AML discussions the way car crash statistics are cited in driving safety briefings correctly but with the implicit assumption that the audience is thinking ‘that would never happen to us.’
The assumption is reasonable for a fintech at seed stage. FinCEN is not sending examiners to a lending platform that has processed $2 million in loans. But the habits you build when you are small the architectural decisions, the written programme design, the actual functioning of your compliance operation — are the same habits that either hold up or do not when you are large.
Building a compliance programme that runs alongside your lending operation rather than inside it is not a catastrophic failure at Series A. It becomes one at Series C, when transaction volume has reached the point where the timing gaps are large enough to matter, the data completeness gaps are large enough to flag on examination, and the audit trail fragmentation is large enough to turn a regulatory enquiry into a project.
The architecture decision is made once. Its consequences play out over years.
What Compliance-Native Looks Like in Practice
A compliance-native AML architecture is not magic. It is a design choice made at the point when the lending platform is being built, before the compliance layer is added — specifically, to not add a compliance layer, but to make compliance part of the core architecture.
In practical terms, this means:
- SAR generation is triggered by the same event processing engine that handles loan origination and servicing — not by a separate monitoring system that receives a data feed
- OFAC screening runs before a transaction is committed to the ledger — not after, not asynchronously, not in a parallel process
- PEP identification happens at onboarding as part of the same customer record creation that creates the borrower account — not as a separate check that is matched against the account afterwards
- The investigator dashboard is connected directly to the lending platform’s transaction history not to an export of that history that was pushed to the compliance tool on a schedule
- The audit trail is a single record — the compliance events and the lending events are entries in the same data store, not records in two systems that are reconciled by a monthly process
The result is not a different level of compliance capability. It is the same capability with fundamentally different reliability, completeness, and audit trail quality. And it is the architecture that regulators are starting to expect from fintech lenders who present themselves as having sophisticated compliance programmes.
The Right Time to Think About This
The right time to think about compliance architecture is before you choose your lending platform. Not after go-live, not after your first regulatory examination, not after a suspicious transaction that you handled correctly but cannot document completely.
The question to ask of any lending platform vendor is not ‘do you have AML compliance features?’ Every platform with any regulatory credibility will say yes. The question is: ‘Does the AML engine run in the same transaction as the lending event, on the same data model, with no external API call in the compliance path?’
If the answer is ‘yes,’ you are looking at a compliance-native architecture. If the answer involves the words ‘integration,’ ‘module,’ ‘partner,’ or ‘third-party,’ you are looking at compliance-added.
Both can be operated compliantly. Only one of them makes that operation straightforward.
