Build vs. buy automated risk monitoring: a decision framework and 15 provider questions

Most fintechs should buy automated risk monitoring and build only the rules specific to their product. The real choice is between point solutions (separate KYC, screening, and monitoring vendors) and an integrated payments and compliance provider. Either way, regulatory responsibility stays with the fintech, so pick the option whose logic you can explain to an examiner.

This article is general information, not legal advice.

Key takeaways

• There are three operating models, not two: build in house, buy point solutions, or use a provider that runs compliance inside the payment flow.
• Responsibility never transfers. Under 31 CFR 1022.210, the AML program belongs to the money services business, whoever runs the software.
• The rules engine is the cheap part of building. List feeds, wallet analytics, case management, and audit evidence are the expensive parts.
• Pick on six inputs: jurisdictions, volume, rails, team size, audit needs, and speed to market.
• Evaluate providers on what they can export and explain, not on the demo.

Automated risk monitoring covers four jobs: verifying customers, monitoring transactions, screening against sanctions lists, and working the resulting alerts. The automated risk monitoring explainer takes each one apart. This guide answers a different question: who should run them.

What are the three ways to run automated risk monitoring?

A fintech can build monitoring in house, buy point solutions and connect them, or use an integrated provider that runs the checks inside the payment flow. Each model trades control for time and maintenance.

Look at the "Regulatory responsibility" column. It never says "the vendor's."

Does buying compliance transfer regulatory responsibility?

No. Buying a tool or a provider shifts who operates the checks, not who answers for them.

Three rules make that concrete:

• FinCEN. Under 31 CFR 1022.210, a money services business must have its own AML program: policies and internal controls, a designated compliance officer, training on detecting suspicious transactions, and independent review whose scope and frequency match the firm's risk. A vendor contract is an input to that program, not a substitute for it.
• OFAC. OFAC's sanctions compliance guidance for the virtual currency industry states that civil penalties generally rest on a strict liability standard. A US person can be liable even without knowing or having reason to know. "Our screening vendor missed it" is not a defense.
• FCA. The UK Financial Crime Guide lists, as poor practice, threshold-based monitoring that is poorly calibrated and firms that struggle to explain why particular rules exist. A black-box vendor makes that failure likely.

The practical test: could your compliance officer explain, in writing, every rule running on your customers and why its threshold sits where it does? If the answer depends on a vendor support ticket, the program has a gap.

How do you decide which model fits?

Answer six questions in order. The first three decide what has to be covered; the last three decide how much of it you can run yourself.

1. Which jurisdictions? Count the markets where customers sit and where money lands. Each one adds sanctions lists, Travel Rule thresholds, and registry checks. Two or more markets push hard toward buying.
2. What volume, now and in 18 months? Low volume makes per-check pricing cheap and in-house analysts affordable. High volume makes alert noise the main cost. See how to reduce false positives before modeling analyst headcount.
3. Which rails? Stablecoin transfers are final once confirmed, so checks must run before settlement. Bank rails add their own screening and data rules. Mixed rails favor a provider that monitors the whole payment, not just one leg.
4. How big is the compliance team? One part-time officer cannot maintain list feeds, tune rules, and work cases. Two or three people can run point solutions. A full team with data engineering can consider building.
5. What will auditors and partners ask for? Partner banks and examiners want case trails, rule rationale, and testing records. If you can't produce those from a vendor, you'll be building them anyway. Audit-ready risk monitoring lists the evidence.
6. How fast do you need to launch? If a corridor launch is weeks away, only the integrated model fits. Building is a multi-quarter project, not a sprint.

Most teams land on a hybrid: buy the core checks, then write product-specific rules and own the oversight.

What does building in house actually involve?

Building means owning five systems, and the rules engine is the smallest one.

• Data feeds. OFAC, UN, EU, and UK lists, PEP data, and adverse media, refreshed every time a list changes. Ongoing sanctions screening covers why cadence matters.
• Wallet analytics. OFAC lists some wallet addresses, but its FAQ 562 says those listings are not likely to be exhaustive. Address risk needs blockchain analytics.
• Rules and models. The 12 red flags are a starting library. Each rule needs a documented rationale, test cases, and a recalibration date.
• Travel Rule handling. Counterparty identification, data validation, and hold or return logic. The Travel Rule workflow shows the decision points.
• Case management and audit logs. Every alert, decision, reviewer, and timestamp, retained for five years.

Then the program around it: independent review, training, and change control. The broader payments version of this question, wallets and rails included, sits in build vs buy stablecoin payments.

What are 15 questions to ask a compliance provider?

These complement the five criteria in how to choose a risk monitoring vendor. That page covers coverage, integration, false positives, pricing, and audit output at a high level. These questions go into operations and exit.

1. Which sanctions, PEP, and adverse media lists do you screen, and how soon after a list update does rescreening run?
2. Do you screen wallet addresses, on which chains, and against what beyond the SDN List?
3. How do you handle the Travel Rule: which thresholds, which data, and what happens when a counterparty sends incomplete data?
4. Can my team see and tune thresholds, or only request changes through support?
5. How is a rule change validated before it goes live, and is the before-and-after alert volume recorded?
6. Can I export the full audit log (inputs, checks, results, reviewer, timestamps) in a structured format, on demand?
7. Do you provide case management, or do alerts land in my own tooling?
8. What is the SLA for manual review, and what happens to the payment while it waits?
9. Where is customer data stored and processed, and under which privacy regimes?
10. How are failed or rejected payments handled: refunded to the source, held, or failed for support to resolve?
11. Is pricing published, and which checks cost extra?
12. Which regulators are you registered or licensed with, and where can I verify it?
13. What is your incident process when a screening feed or rule breaks, and how fast am I told?
14. Is the API documented publicly, with a sandbox that returns approve, review, and reject outcomes?
15. If we leave, how do we get customer records, case history, and audit logs out, and in what format?

For the payment side of the same due diligence (custody, liquidity, rails), use the provider due diligence checklist.

When is a human reviewer still required?

A human must decide whenever the outcome carries legal weight or ends a customer relationship. Automation prepares those cases; it does not close them.

• Possible sanctions matches that secondary identifiers can't clear.
• Enhanced due diligence for high-risk customers and jurisdictions.
• SAR decisions. Under 31 CFR 1022.320, an MSB files within 30 calendar days of initial detection, and a person owns that call.
• Customer exits and blocked payments.
• Rule changes, which a compliance officer signs off.

This matches the direction in the Wolfsberg Group's 2025 statement on monitoring innovation: new tools are fine, but they need validation and explainable outputs. Automation can score, deduplicate, gather evidence, and draft narratives, which is what compliance agents do.

What does this look like in practice?

Illustrative example (all numbers hypothetical): a fintech pays contractors in Brazil and Mexico in USDC, with 2,000 customers and two people in compliance.

• Build: list feeds, wallet analytics, a rules engine, case management, and audit logging. Two compliance staff can't maintain all of that and work cases. Launch slips by quarters.
• Point solutions: a KYC vendor, a screening vendor, and a monitoring vendor. Each integrates in weeks. The team then writes the join between customer profiles and alerts, and every exam question becomes a lookup across three systems.
• Integrated provider: KYC, screening, and monitoring run inside the payout flow. The team spends its time on oversight: reviewing held payouts, writing two product-specific rules (contractor payments above a monthly baseline, new bank accounts added within 24 hours of a payout), and testing them.

With two people and a launch date, the third option wins. With ten people and a regulator asking for model governance, the second may.

What are the common mistakes in build vs. buy decisions?

• Buying on the demo. A demo shows the happy path. Ask for a sample case file and an audit export instead.
• Accepting a black box. If the provider can't explain why a rule fired, your compliance officer can't either. That fails the FCA's calibration test and most partner bank reviews.
• Ignoring audit exports. Data you can't export is evidence you can't show. Check the format before signing.
• Underestimating in-house maintenance. Lists change, typologies shift, and thresholds drift. Rules written at launch are wrong within a year without recalibration.
• Treating the vendor as the compliance officer. The vendor operates tools. Someone on your team owns the program.
• Forgetting exit. Five years of records must survive a vendor change.

How does BlindPay fit the integrated model?

BlindPay is one example of the integrated model. It is registered with FinCEN as a money services business, with registrations on the licenses page. KYC, KYB, sanctions screening, Travel Rule compliance, and transaction monitoring run inside the API flow, before money moves. KYC Standard is automated and takes about 60 seconds; KYC Enhanced and KYB Standard are manual reviews that take 3 hours to 1 business day.

A flagged payment moves to on_hold and compliance reviews it, as described in on-hold transactions. A refunded payout returns stablecoins to the wallet that funded it; a failed payout doesn't refund automatically. Plans are published on the pricing page. Your team still owns its program, its customers, and its oversight, and the 15 questions above apply to BlindPay the same way they apply to anyone else.

What to do next

Answer the six framework questions on one page, then send the 15 provider questions to two or three candidates, including any payment provider already in your stack. Ask each for a sample audit export and case file. The provider that sends real artifacts within a day is usually the one whose product does the work.

Sources and further reading

• 31 CFR 1022.210, AML programs for money services businesses
• 31 CFR 1022.320, suspicious activity reports by money services businesses
• OFAC, Sanctions Compliance Guidance for the Virtual Currency Industry
• OFAC FAQ 562, digital currency addresses on the SDN List
• FCA Financial Crime Guide, FCG 3.2
• Wolfsberg Group Statement on Effective Monitoring for Suspicious Activity, Part II

This article is general information, not legal advice.