Fintech Compliance RFP: Multi-Jurisdiction Vendor Guide 2026

A fintech compliance RFP fails when it asks one question of vendors that solve different problems. Compliance automation is modular: AML/KYC platforms, transaction monitoring engines, regulatory change tools, and regulatory reporting systems are separate products with separate buyers, data models, and proof points. This page gives compliance and procurement leaders a longlist split into those four categories, a scoring rubric that works across them, and questionnaire templates for multi-jurisdiction programs.

Key takeaways

• The global KYC and KYB software market reaches $35.5 billion in 2026 and is projected to grow to $53 billion by 2030 (Juniper Research).

• Four RFP categories keep vendors comparable: AML/KYC/KYB, transaction monitoring and investigations, regulatory change management, and regulatory reporting with evidence infrastructure.

• The EU Anti-Money Laundering Regulation (AMLR, Regulation (EU) 2024/1624) applies directly in all Member States from 10 July 2027. The Anti-Money Laundering Authority (AMLA), established under Regulation (EU) 2024/1620, begins direct supervision of its first high-risk, cross-border obliged entities on 1 January 2028 (AU10TIX).

• Up to 90% to 95% of AML and sanctions screening alerts are false positives (Signzy, April 2026). False-positive handling belongs in every category's requirements, not only monitoring.

• McKinsey reports that agentic AI in anti-financial-crime compliance can lift productivity by 200% to 2,000%, with one human supervising 20 or more AI agents in structured workflows. That only holds when every agent decision can be replayed against stored evidence.

How to structure a fintech compliance automation RFP

Most multi-jurisdiction RFPs go wrong at the first step: the vendor list mixes a KYB platform, a transaction monitoring engine, and a regulatory intelligence feed, then scores them on one sheet. The scores mean nothing, because a regulatory change tool can't onboard a customer and an onboarding platform can't file a report.

Split the RFP into four lots:

1. AML/KYC/KYB: onboarding, identity verification, screening, and perpetual risk updates.

2. Transaction monitoring and investigations: detection, alert triage, case management, and SAR/CTR support.

3. Regulatory change management: horizon scanning and mapping changes to policies and controls.

4. Regulatory reporting and evidence infrastructure: producing filings and proving data lineage.

Each lot gets its own vendor list and questionnaire. All lots share one rubric (below) and three non-negotiable properties: field-level evidence, decision replay, and a policy-change process that doesn't depend on an engineering release. Where one vendor bids on several lots, score each lot separately.

A note on the lists: Duna appears in Category 1 and is scored by the same rubric as every other vendor. Fit notes reflect each vendor's public positioning. Treat them as hypotheses to test in the RFP, not conclusions.

Category 1: AML/KYC/KYB for onboarding and perpetual risk updates

Category 1 covers verifying a customer, screening the entity and its ultimate beneficial owners (UBOs) against sanctions and PEP lists, reviewing corporate documents, and re-verifying on a continuing basis. For fintechs the work has a different shape than at banks. The customer is often a small business onboarding inside an app, so every extra document request is a drop-off. Most fintechs run more than six vendors across the lifecycle with no layer connecting them (Duna AI memo).

Three of these vendors deserve a closer read because they represent different architectures.

Duna stores identity data as discrete pieces of evidence under a policy engine, and virtual agents run on top to evaluate documents, registry data, adverse media, and websites. Policy changes go live without engineering, and every agent decision can be reproduced against the underlying evidence. Duna's virtual screening assistants cut false positives by roughly 70% versus legacy screening stacks (Duna AI memo). Customers report 10.6x faster onboarding, a 37% conversion increase, and 4.8x analyst efficiency. The platform is ISO 27001, SOC 2, and GDPR certified, with customer data stored in the EU. Customers include Plaid, CCV (Fiserv), Moss, and Bol.

Alloy was founded in New York in 2015 and serves more than 700 financial institutions and fintechs. It has raised $211 million and was last valued at $1.55 billion. The strength is the existing US footprint and the breadth of third-party data providers it orchestrates. The trade-off is architectural: the record is the workflow trace rather than an evidence-first data model, and policy changes flow through the orchestration layer rather than a dedicated policy engine.

Fenergo was founded in Dublin in 2009 and counts around 70 global financial institutions as clients. Its strength is depth and audit pedigree from large-bank deployments. The trade-off for a fintech is implementation weight: contracts for top-100 banks have been reported at $3 million to $5 million per year on four-year terms, and deployments typically cover one line of business at a time.

For a deeper view on ownership resolution, see this comparison of UBO mapping vendors. For EU-specific coverage, the ranking of European corporate onboarding agents goes further.

Must-ask RFP questions for Category 1

• Which evidence fields are stored per entity (registry extract, document, screening hit, website check), and can each field be traced to its source and timestamp?

• How is UBO coverage resolved, and to what ownership depth, per jurisdiction?

• Which events trigger re-KYC (list change, ownership change, registry movement), and which wait for the calendar?

• Who can change a policy, how fast does it go live, and is the change logged with author and approval?

• Can an auditor re-run a historical decision and get the same answer?

Buyers who need the full bank-side checklist can use bank-grade KYB RFP requirements alongside this page.

Category 2: Transaction monitoring and investigations

Category 2 is where false positives cost the most. If 90% to 95% of alerts are false (Signzy, April 2026), analyst headcount scales with alert volume unless the engine triages well. Evaluate detection, triage, case management, and regulator-ready outputs as one chain.

Enterprise suites bring depth and implementation weight. Fintech-oriented tools bring faster deployment and less breadth of regulator-specific output. Decide which trade-off your jurisdictions require before you shortlist.

Must-ask RFP questions for Category 2

• How does the vendor reduce false positives, and what baseline and measurement method does it use?

• Which tuning controls can compliance change directly, and how is every threshold change logged?

• Can the vendor explain why an alert fired in terms an examiner would accept?

• How does monitoring consume onboarding and KYC data, such as risk rating and UBO structure?

• Which SAR/CTR workflows and jurisdiction-specific formats are supported out of the box?

Category 3: Regulatory change management

Category 3 answers a different question: when a rule changes in one of your jurisdictions, how fast does it reach a policy and a control? With AMLR applying from 10 July 2027, EU-active fintechs will run change programs on a fixed deadline while other jurisdictions keep moving.

Regulatory change tools track and map obligations. They don't execute them. The gap between "we know the rule changed" and "the onboarding policy now enforces it" is where programs stall, so ask each vendor how a mapped obligation becomes a changed control.

Must-ask RFP questions for Category 3

• Which jurisdictions and regulators are covered, in which languages, and with what update frequency?

• Is obligation extraction human-curated, AI-generated, or both, and how is accuracy validated?

• How does the tool map an obligation to your policies and controls, and can that mapping export to your policy engine or GRC system?

• How is impact assessed, assigned, and tracked to closure?

• What audit evidence does the tool generate for each change?

Category 4: Regulatory reporting and evidence infrastructure

Category 4 produces filings and proves where every number came from. Supervisors judge reports by lineage: if a figure can't be traced to source data, the report fails the review even when the number is right.

These are enterprise platforms. Smaller fintechs often meet reporting duties with templates inside a Category 1 or 2 product, plus an evidence store. Scope this lot by your actual filings, not by the vendor's regulator count.

Must-ask RFP questions for Category 4

• Which regulator templates ship configured, and who maintains them when formats change?

• Is lineage captured from source system to filed value, automatically and at field level?

• What validation runs before submission, and what happens to failed checks?

• Can the system reproduce a filing as submitted, with its inputs, on a given historical date?

Evaluation rubric for scoring unlike vendors

Score every vendor in every lot on the same six criteria, 1 to 5, then apply weights. The weights below are a starting point for a multi-jurisdiction fintech. Adjust them to your risk profile before the RFP goes out.

Add one cross-cutting metric for the pilot: false-positive rate against your own historical alert set. Vendors that decline to run it have told you something.

Failure modes to screen for

• Workflow tools without evidence-first data. The record is a trace of steps, so an auditor can see what ran but not why a field held a given value.

• Weak jurisdiction mapping. The vendor claims 100 countries but resolves most through a single global data provider, with no local registry access.

• Slow policy execution. A rule change requires a ticket, a release window, and a regression test. Compliance policies change roughly every six months at a typical fintech, so slow execution means constant drift.

• Calendar-based review. The system waits for a 12, 24, or 36-month cycle instead of reacting to a sanctions list change, UBO shift, or registry movement.

• Black-box AI. Agent outputs can't be reproduced, which fails the explainability bar supervisors apply.

• Bundle blur. A suite is scored as one product, hiding that one module is strong and three are thin.

The EU AMLA timeline raises the bar for evidence and policy speed

AMLA, based in Frankfurt, begins direct supervision of up to forty obliged entities on 1 January 2028, after AMLR applies on 10 July 2027. The selected set isn't banks alone. Credit institutions, financial institutions, payment service providers, and, for the first time at EU level, crypto-asset service providers fall in scope. Selection rests on operating in six or more Member States with high residual risk, so pan-European payments providers, crypto exchanges, and embedded-finance platforms should expect to be in the pool.

For procurement, the consequence is concrete. RFPs issued in 2026 will go live close to the AMLR date, so require per-field audit trails, continuous risk assessment instead of periodic snapshots, and policy-change cycles measured in days. Platforms built for the pre-AMLA regime, with multi-quarter policy cycles and limited audit detail, will need significant rework to meet it.

Implementation planning by phase for multi-jurisdiction programs

Ask each shortlisted vendor to answer by phase, not in the abstract.

Discovery

• Which data model and evidence fields will be configured, and who signs off?

• Which jurisdictions go live first, and which registries or data sources back each one?

• What does the vendor need from your teams, and in which weeks?

Pilot

• Which routing rules, alert volumes, and false-positive thresholds will be tested?

• Will the vendor run your historical cases, and report the false-positive rate against your baseline?

• Can the pilot include an evidence replay test, where an auditor picks a case at random and the system reproduces the decision?

Rollout

• Who governs policy changes after go-live, and what is the approval chain?

• How are monitoring and model performance reported, and how often?

• How is ongoing control evidence packaged for internal audit and supervisors?

Legacy enterprise platforms typically take 12 to 24 months for a single product line. SaaS platforms with policy-driven agents can land a first use case in three to six weeks. Use those ranges to test whether a vendor's proposed timeline is credible.

Track the same indicators from pilot through rollout:

• End-to-end business onboarding conversion rate

• Median and 95th percentile time to first decision

• False-positive rate on screening and monitoring alerts

• Cost per review, including analyst time

• Share of reviews triggered by a real-world signal rather than the calendar

• Time from policy authoring to live execution

• Coverage of UBO changes between scheduled reviews

Appendix: RFP questionnaire templates

Copy the block for each lot you're buying. Ask vendors to answer in a structured format, with evidence attached where indicated.

AML/KYC/KYB questionnaire

1. List the countries where you access local company registries directly, and name the registry.

2. Describe the evidence fields stored per entity and how each links to its source.

3. How deep does UBO resolution go, and how do you handle nominee or trust structures?

4. Which screening lists and adverse media sources do you cover, and how often are they refreshed?

5. How do you handle PEP and sanctions matches, and what tools support analyst review?

6. List the events that trigger re-KYC automatically.

7. Describe how a compliance user authors and publishes a policy change, including approvals.

8. Provide the median time from policy request to live execution for the last five changes.

9. Demonstrate decision replay on a past case, live.

10. How does the platform handle provider outages and fallback?

11. What onboarding conversion data do you measure per step?

12. Which languages does the applicant interface support?

Transaction monitoring questionnaire

1. Which detection methods (rules, behavioral models, network analysis) are available, and how are they combined?

2. Provide your false-positive rate method and benchmarks, with customer references.

3. Which tuning controls can customers change without vendor involvement?

4. How are threshold and model changes logged and approved?

5. Describe how an alert is explained to an analyst and to an examiner.

6. How does case management handle escalation, four-eye review, and SAR drafting?

7. Which SAR/CTR formats are supported, and for which regulators?

8. How does the system ingest KYC risk ratings and ownership data?

9. What is the data latency from transaction to alert?

10. Describe backtesting and model validation support.

Regulatory change management questionnaire

1. Which regulators and jurisdictions do you cover, and in which languages?

2. How often is content updated, and what is the SLA for a new rule?

3. How are obligations extracted, validated, and versioned?

4. How does the tool map obligations to your policies, controls, and owners?

5. Describe impact assessment workflows and reporting.

6. Which audit evidence does the tool produce for each change?

7. How can mappings export to a policy engine, GRC tool, or ticketing system?

8. How do you disclose the role of AI in content creation and what review process applies?

Regulatory reporting questionnaire

1. List the regulator templates maintained and the process for format changes.

2. Describe lineage capture from source to filed value.

3. Which validation rules run before submission?

4. Can you reproduce a filing as submitted, with inputs and logic version?

5. How are reconciliations between sources handled?

6. Provide implementation references for a comparable jurisdiction mix.

7. What controls prevent unauthorized changes to report logic?

Integration and security questionnaire (all lots)

1. Provide API documentation, rate limits, and webhook support.

2. List prebuilt connectors to data providers, cores, and case tools.

3. Share current SOC 2 Type II and ISO 27001 reports.

4. Where is customer data stored, and which residency options exist?

5. Describe encryption at rest and in transit, and key management.

6. Describe role-based access, SSO, and four-eye controls.

7. State incident response commitments and breach notification times.

8. How is customer data used in model training, if at all?

Frequently asked questions

How do we avoid comparing unlike vendors in a compliance automation RFP?
Run separate lots for AML/KYC/KYB, transaction monitoring, regulatory change management, and regulatory reporting. Score each vendor by lot, using the shared rubric, and never let a suite's strongest module raise its score on a weaker one.

What does policy execution speed mean in procurement terms?
It's the time from an approved policy change to that change enforced in production, measured in elapsed hours or days. Ask for the median across the last five customer changes and whether the compliance team made them without engineering. Fintech policies change about every six months, so a release-window dependency creates constant drift.

What evidence proves auditability?
Request a live decision replay: pick a historical case, re-run it, and check that the decision and its supporting evidence match what was recorded. Also request the audit log schema, the retention period, and a sample export. Field-level lineage is a separate test from step-level logs.

Can AI replace compliance analysts?
Agents don't replace analysts. They reduce workload by automating evidence collection, screening, and document review, with humans supervising outcomes. McKinsey reports one person supervising 20 or more agents in well-designed financial-crime workflows. Treat that ratio as valid only where decisions are reproducible against stored evidence.

What is the difference between KYC and KYB software?
KYC verifies individuals. KYB verifies businesses, including layered ownership, cross-border entities, and UBO structures that scheduled reviews routinely miss. In a multi-jurisdiction RFP, KYB is usually the harder lot.

Which regulations should an EU-active fintech plan for?
AMLR applies from 10 July 2027 and AMLA starts direct supervision of up to forty obliged entities from 1 January 2028. Fintechs operating in six or more Member States with high residual risk should assume they're in the selection pool and write evidence trails, continuous monitoring, and fast policy change into the RFP.