Table of Contents
Summarize and analyze this article with
The two layers you are actually buying
BSA/AML technology is sold as a single purchase, but it is really two. Layer one is the detection engine transaction monitoring, sanctions screening, case management. Layer two is the governed data feeding it entity resolution, signal quality, lineage. Most banks evaluate layer one exhaustively and layer two barely at all, which is exactly backwards, because most false positives originate in layer two.
The ROI math worth front-loading
At an anonymized top-25 US bank, financial-crimes data engineering entity resolution, signal enrichment, governed lineage contributed to a 68% reduction in BSA/AML false positives and a 43% reduction in compliance overhead. Most of the lift came from the data layer, not from threshold tuning. The buying implication: weight your evaluation toward layer two.
A neutral map of the solution categories
The single most important line in SR 26-2 is what it leaves out. Generative and agentic AI are excluded from scope while separate guidance is developed a governance gap the bank owns in the interim. Traditional MRM controls, designed for statistical and ML models, do not reach prompt usage, sensitive-data exposure, hallucination, the need for human review of material outputs, output logging, or for agentic AI which actions an autonomous agent may take without approval.
| Category | What it does | Decision |
|---|---|---|
| Transaction monitoring engines | Rules + behavioral models that generate alerts | Buy — mature market |
| Sanctions / watchlist screening | Name and payment screening against reference lists | Buy — reference data + matching logic |
| Case management & SAR workflow | Investigation, disposition, regulatory filing | Buy / configure |
| Entity resolution & data quality | Unifies identities; fixes the inputs alerts depend on | Build / partner — highest leverage |
| Lineage & audit evidence | Traces any alert to source for analysts and examiners | Build / partner |
| Model monitoring & feedback | Drift detection; case outcomes wired back into models | Build / partner |
The five data inputs that decide detection quality
Before scoring any engine, assess the condition of the data it will consume. Five inputs do most of the work:
- Customer and entity data poor entity resolution fragments one customer into many and corrupts every downstream score.
- Transaction data completeness and cross-channel consistency determine whether monitoring sees the full picture.
- Sanctions and watchlist data screening is only as good as the reference data and matching logic.
- Case and investigation history the feedback that should sharpen the model, too often stranded in the case system.
- Lineage and audit evidence the ability to trace any alert from output back to source, which examiners increasingly expect on demand.
The 9-factor vendor evaluation matrix
Score each option 1–5. Detection quality and explainability predict program success; demo polish does not.
| # | Factor | What ‘good’ looks like |
|---|---|---|
| 1 | Detection quality on YOUR data | Proof of false-positive reduction on data like yours, not a generic benchmark |
| 2 | Entity resolution support | Strong identity unification or clean integration with a partner who provides it |
| 3 | Explainability | Every alert traceable to the signals and logic that produced it |
| 4 | Examiner-ready evidence | Lineage and audit trail produced as a by-product |
| 5 | Model monitoring | Drift detection and case-feedback loops, not static thresholds |
| 6 | Data integration effort | Realistic estimate of source mapping and remediation, not ‘plug and play’ |
| 7 | Regulatory alignment | Consistent with SR 26-2 model-risk expectations where AI is used |
| 8 | Total cost of ownership | License + integration + run, over three years |
| 9 | References | Peer banks; closed examiner findings under NDA |
Build vs. buy for BSA/AML
- Buy the monitoring, screening, and case-management engines the category is well served and building offers little advantage.
- Build (or partner for) entity resolution, signal enrichment, and governed lineage bank-specific work that determines alert quality and examiner-readiness.
- Integrate case outcomes back into model retraining so the program improves over time instead of decaying.
What examiners now expect
A TCO model and the false-positive business case
Model TCO in three buckets license, integration and data foundation, and run and weigh it against the cost of the status quo. The status-quo cost is usually larger than buyers expect: every false positive consumes analyst time, and a high false-positive rate quietly funds a small army of investigators reviewing noise. Reducing false positives returns that capacity to genuine risk. That is the business case, and it is why the data layer where the reduction actually comes from deserves the heaviest evaluation weight.
A 90-day path to better signal
- Profile the five data inputs and quantify the defects driving false positives.
- Fix entity resolution first the highest-leverage move on alert quality.
- Establish lineage so every alert is traceable for analysts and examiners.
- Wire case outcomes into the model and instrument drift monitoring.
- Then tune thresholds on governed inputs and document the evidence trail.
How PiTech approaches BSA/AML technology selection and delivery
PiTech is a practical implementation partner for regulated U.S. banks. On financial crimes the work is data engineering as much as modeling: improving entity resolution and signal quality, rebuilding governed lineage, wiring case feedback into models, monitoring drift, and producing audit-ready evidence — integrated with whichever monitoring engine fits the bank. Where buying an engine is the right call, PiTech says so and integrates it. Outcome reference: the top-25 US bank result above, delivered by senior practitioners under CMMI Level 3 and ISO-certified security discipline.
Frequently Asked Questions (FAQs)
How do you evaluate BSA/AML technology vendors?
Evaluate two layers separately: the detection engine (monitoring, screening, case management usually bought) and the governed data feeding it (entity resolution, signal quality, lineage usually built). Score vendors on detection quality demonstrated on data like yours, entity-resolution support, explainability, examiner-ready evidence, model monitoring, realistic integration effort, regulatory alignment, three-year total cost of ownership, and peer references with closed examiner findings. Weight the data layer heavily that is where false positives originate.
Should a bank build or buy AML technology?
Buy the monitoring, screening, and case-management engines the market is mature and building offers little advantage. Build, or partner for, entity resolution, signal enrichment, and governed lineage, because these are bank-specific and determine alert quality and examiner-readiness. Then integrate case outcomes back into model retraining. Buying an engine without addressing the data layer underneath is the most common reason AML programs keep generating noise.
Why are BSA/AML false positives so high, and how do you reduce them?
Most false positives originate in the data, not the model: fragmented entity data so one customer appears as several, inconsistent transaction data across channels, and broken lineage. Reducing them durably means financial-crimes data engineering entity resolution, signal enrichment, lineage, and case-feedback loops before threshold tuning. At an anonymized top-25 US bank this approach contributed to a 68% reduction in false positives, with most of the lift from the data layer
What does BSA/AML technology cost?
Model total cost of ownership in three buckets engine license or subscription, integration and data-foundation work (entity resolution, source mapping, lineage, remediation), and ongoing run and evidence upkeep and weigh it against the cost of the status quo. A high false-positive rate quietly funds investigators reviewing noise; reducing it returns analyst capacity to genuine risk. The data-foundation bucket is usually the largest and the one vendors exclude from a license quote.
What do examiners expect from AML technology in 2026?
Examiners now expect banks to show how a control works, not just that it exists: demonstrable lineage for transaction monitoring and sanctions screening, documented model monitoring including drift, retained evidence for alert and suspicious-activity decisions, and AI governance consistent with refreshed model-risk guidance such as SR 26-2 and OCC Bulletin 2026-13 where complex algorithms are used.


