---
title: "Build vs. buy automated risk monitoring: a decision framework and 15 provider questions"
seoTitle: "Build vs buy risk monitoring: framework and 15 questions"
description: "Build, buy point solutions, or use an integrated provider? Compare three ways to run automated risk monitoring, who stays responsible, and 15 questions."
date: "2026-10-05"
updated: "2026-10-05"
category: "compliance"
author: "BlindPay Team"
faq:
  - q: "Should a fintech build or buy automated risk monitoring?"
    a: "Most fintechs should buy, either as point solutions or inside an integrated payments and compliance provider, and build only the product-specific rules on top. Building in house makes sense when monitoring is the product, when volume and risk are unusual enough that no provider fits, or when the team already runs a mature compliance function with data engineers and model validation."
  - q: "Does outsourcing compliance transfer regulatory responsibility to the vendor?"
    a: "No. A money services business must maintain its own AML program under 31 CFR 1022.210, and OFAC sanctions liability is strict for US persons. A vendor can run checks, but the firm still answers to its regulator and its partner bank. It must be able to explain which rules run, why the thresholds sit where they do, and how alerts were decided."
  - q: "What is the difference between point solutions and an integrated compliance provider?"
    a: "Point solutions are separate vendors for KYC, sanctions screening, and transaction monitoring that the fintech connects itself. An integrated provider runs those checks inside the payment flow, so the customer profile, the screening result, and the payment decision sit in one system. Point solutions offer more control per layer; integration removes the joins the fintech would otherwise build and maintain."
  - q: "What should I ask a compliance provider before signing?"
    a: "Ask which lists are screened and how often they refresh, whether wallet addresses are covered, how the Travel Rule is handled, who can tune rules and how changes are validated, what the audit log export contains, the SLA for manual review, how failed payments are handled, and how you leave with your data. Ask for sample exports, not a demo."
  - q: "How long does it take to build transaction monitoring in house?"
    a: "The rules engine is the short part. Sanctions list feeds, wallet address analytics, case management, audit logging, rule testing, and staff to work the alerts take far longer, and each needs documentation an examiner will read. Teams starting from zero usually spend many months before the program is examination-ready, and the maintenance never stops."
  - q: "When does a human still need to review automated monitoring alerts?"
    a: "Always for decisions with legal weight: clearing a possible sanctions match, approving a high-risk customer under enhanced due diligence, deciding whether to file a suspicious activity report, and exiting a customer. Automation can score, deduplicate, gather evidence, and draft a narrative. A named person signs off on the outcome and owns the reasoning."
---

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](/resources/more/what-is-automated-risk-monitoring-fintech) 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.

| Option | Time to launch | Ongoing cost drivers | Control and customization | Regulatory responsibility | Best for |
| --- | --- | --- | --- | --- | --- |
| Build in house | Longest. Many months before an examination-ready program | Engineers, data feeds, analytics licenses, analysts, model validation, independent review | Full. Every rule, threshold, and model is yours | Fully yours, including every design choice | Firms where monitoring is the product, or with unusual risk no vendor covers |
| Buy point solutions | Medium. Each vendor integrates fast; the joins between them take longer | Per-check or platform fees per vendor, integration upkeep, analysts | High per layer, limited across layers | Yours. Vendors supply tools, you own the program and the joins | Teams with a compliance function that want best-of-breed per layer |
| Integrated payments and compliance provider | Shortest. Monitoring comes with the payment integration | Bundled in payment pricing, plus your own review and oversight time | Lower. You configure inside the provider's model and add your own rules on top | Yours for your program and your customers; the provider also carries its own obligations | Startups and fintechs that want to launch corridors without standing up a full stack |

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](https://www.law.cornell.edu/cfr/text/31/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](https://ofac.treasury.gov/media/913571/download?inline) 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](https://handbook.fca.org.uk/handbook/FCG/3/2.html) 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](/resources/more/reduce-false-positives-transaction-monitoring) 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](/resources/more/aml-audit-readiness-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](/resources/more/ongoing-sanctions-screening-how-often-to-rescreen) covers why cadence matters.
- **Wallet analytics.** OFAC lists some wallet addresses, but its [FAQ 562](https://ofac.treasury.gov/faqs/562) says those listings are not likely to be exhaustive. Address risk needs blockchain analytics.
- **Rules and models.** The [12 red flags](/resources/more/transaction-monitoring-red-flags-stablecoin-payments) 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](/resources/more/travel-rule-workflow-hold-return-reject) 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](/resources/more/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](/resources/more/how-to-choose-automated-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](/resources/more/stablecoin-payments-provider-due-diligence).

## 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](https://www.law.cornell.edu/cfr/text/31/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](https://wolfsberg-group.org/resources/202) 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](/resources/more/what-are-compliance-agents-in-fintech) 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](/licenses). 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](/docs/kb/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](/pricing). 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](https://www.law.cornell.edu/cfr/text/31/1022.210)
- [31 CFR 1022.320, suspicious activity reports by money services businesses](https://www.law.cornell.edu/cfr/text/31/1022.320)
- [OFAC, Sanctions Compliance Guidance for the Virtual Currency Industry](https://ofac.treasury.gov/media/913571/download?inline)
- [OFAC FAQ 562, digital currency addresses on the SDN List](https://ofac.treasury.gov/faqs/562)
- [FCA Financial Crime Guide, FCG 3.2](https://handbook.fca.org.uk/handbook/FCG/3/2.html)
- [Wolfsberg Group Statement on Effective Monitoring for Suspicious Activity, Part II](https://wolfsberg-group.org/resources/202)

*This article is general information, not legal advice.*