Three pipeline design decisions that determine whether your AML model survives its first regulatory examination

The FinCEN enforcement actions of recent years share a recurring pattern: the institution had detection tooling, it had rules, it even had ML models. What it lacked was a pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition → it could explain. When the FCA, FinCEN, or a state DFI examiner asks why a specific Monzo customer was cleared at onboarding in March 2025 and then triggered a SAR six months later, "our model scored them low" is not an answer. The audit trail, the feature lineage, the threshold rationale, all of it must be reconstructable on demand.

For fintechs, the stakes are sharper than for incumbent banks. A neobank or payment processor operating under an EMI license has thinner compliance staff, higher transaction velocity relative to headcount, and regulators who are increasingly skeptical that technology substitutes for governance. The pipeline design choices you make in the next quarter will either give you that defensibility or leave you exposed.

How do you build an AML pipeline that survives examination?

Step 1: fix identity resolution before training any model

Every downstream fraud and KYC decision is only as good as your entity graph. Start by consolidating identity signals across your onboarding APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, your core ledger, open banking data feeds (via PSD2 consented connections), device fingerprinting, and any bureau data you pull from Experian, Onfido, or similar providers. The common failure is treating these as separate tables joined at query time. Build a persistent entity resolution layer, a graph that links accounts, devices, phone numbers, and behavioral profiles into unified customer nodes. Jumio and Sardine both publish architecture references for this; treat them as starting points, not blueprints, because your data contractsdata contractsA formal agreement between the team that produces data and the teams that use it, defining structure, meaning, quality and who is accountable when it breaks.View full definition → will differ.

This layer also determines yoursanctions screening and KYC matching quality. Fuzzy matching against OFAC, HMT, or EU consolidated lists is only useful if the name and date-of-birth fields feeding the match are themselves clean and canonically formatted. Most fintechs have silent data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → failures here that a regulatory examination will surface within the first hour.

Step 2: split real-time fraud scoring from investigation-grade analysis

These are architecturally different problems. Real-time fraud scoring at card authorization or payment initiation requires sub-200ms latency. That means feature stores with pre-computed velocity counts, lightweight gradient boosting models (XGBoost or LightGBM are still the workhorses here in 2026 despite the LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition → wave), and hard rule overlays for obvious patterns like card-not-present transactions from a new device in a high-risk jurisdiction.

Your investigation-grade pipeline runs on a different cadence. This is where you build the behavioral baseline per customer, run network analysis to detect mule account rings, compute peer-group anomaly scores, and generate the SAR narrative data that your compliance analysts need. Tools like dbt (vendor disclosure: dbt Labs is a commercial data tooling vendor) can structure the transformation logic here so that every derived feature has a documented lineage back to a raw event. That lineage is what an examiner wants when they pull a sample case.

The mistake fintechs make is trying to serve both use cases from one pipeline. You end up with models too slow for authorization and audit trails too shallow for examination.

Step 3: treat model governance as a pipeline component

Every model that touches a compliance decision needs version control, champion-challenger logging, and threshold change records. This is not optional under FCA SYSC rules or FinCEN examination standards. Practically, this means your model registry must capture: the training data snapshot date, the feature set at the time of the decision, the threshold in effect, and who approved any threshold change and when.

Stripe and Checkout.com have published enough on their ML infrastructure to confirm they treat threshold governance as a change-management process with sign-off from compliance, not just engineering. That is the right model. A risk score of 0.73 that you acted on in January 2026 must be explainable with the same logic in a 2027 examination. If your pipeline overwrites scoring parameters without versioning, you cannot do that.

Thetransaction and behavioral data signals feeding these models also need documented consent and lineage chains, particularly where you are using open banking feeds or third-party enrichment data subject to GDPRGDPREU regulation governing how organizations collect, store and use personal data, with fines tied to global revenue for breaches.View full definition → or CCPA constraints.

What sinks fintech AML pipelines during a regulatory exam?

Running KYC at onboarding as a point-in-time check and never refreshing the risk profile is one of the most cited examination findings. Periodic review cadences must be encoded in the pipeline as triggered jobs, not left to manual analyst scheduling. A PEP who becomes a sanctioned individual eighteen months after onboarding is a real scenario, not an edge case.

Alert fatigue from poorly calibrated rules destroys the compliance function from inside. When your SAR filing rate on alerts is below 3 percent, your rules are likely too broad and your analysts are drowning. Tighten velocity thresholds on a rolling 90-day window per customer segment, not globally across the book.

Data from vendor enrichment sources needs independent validation before you build models on it. A commercial provider's transaction categorization or risk signals are useful features, but they carry the provider's own model biases. If that provider's data is wrong in a systematic way for a specific demographic, your downstream model inherits that bias and your fair lending exposure follows.

Finally, do not let your engineering team own SAR narrative generation in isolation from your compliance analysts. The narrative that goes to FinCEN or the NCA is a legal document. Automating a draft is fine; automating the submission without analyst review is a regulatory violation waiting to happen.

Four audit-trail checks to run on your pipeline this week

• Pull a sample of 50 historical SAR cases and test whether your current pipeline can reconstruct the exact feature values and model score that applied at the time of the alert. If you cannot do this in under an hour, your audit trail has a gap.
• MapMapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → every third-party datathird-party dataData purchased from external aggregators, collected from audiences you don't own. It is bought or licensed rather than gathered through your own direct relationships.View full definition → feed into your KYC and fraud models and document the contractual basis for using that data under GDPR Article 6. Most fintechs find at least one feed with an unclear legal basis.
• Set a calendar trigger for a threshold review meeting with compliance and data science together, quarterly at minimum. Log the outcome in your model registry even if no change is made.
• Check your sanctions screening match rate against a test set of known entities. If your fuzzy match threshold is not tuned, you are likely generating both false positives and false negatives at the same time.

A pipeline that can reconstruct any decision in a sample case, within minutes, with full feature lineage and model version context, will get through most regulatory examinations in reasonable shape. Build for that reconstructability first, and the detection quality will follow from the same discipline.

The full course on this sector:Data in Fintech.