KYC and AML Infrastructure for Regulated Fintechs

Know Your Customer (KYC) and anti-money-laundering (AML) controls are the compliance spine of any regulated fintech. Every onboarding flow, every transaction, every cross-border transfer and every token mint passes through them, and the quality of the infrastructure behind those controls is what separates a firm that scales without supervisory pain from one that spends its senior management attention answering information requests. For a fintech operating in a regulated market, KYC and AML are not a line item under compliance; they are the operating system on which the product sits.

This pillar guide sets out what KYC and AML infrastructure for fintechs actually looks like in 2026. It covers the regulatory drivers, the architectural choice between monolithic vendors and multi-provider orchestration, the role of AI-driven risk scoring, tier-based verification design, Travel Rule integration for firms that touch virtual assets, cost considerations and the build-versus-buy decision. It is written for heads of compliance, heads of engineering, founders and in-house counsel at banks, exchanges, wallets, remittance providers and tokenisation platforms who are designing an onboarding and monitoring stack they expect to operate under supervision for a decade.

Banks have been operating under AML regimes since the 1980s. Their compliance function is mature, their supervisory relationships are stable and their onboarding friction is, for better or worse, accepted by customers who have limited alternatives. Fintechs sit in a different position. They compete with each other on speed, with incumbents on cost, and with unregulated operators on convenience. Their KYC and AML stack has to deliver supervisory-grade controls while producing onboarding experiences that convert. That combination — supervisory substance with product-grade user experience — is not the problem the off-the-shelf compliance industry was built to solve.

The regulatory environment has also moved in a direction that magnifies the stakes. The Financial Action Task Force's (FATF) standards, including Recommendation 10 on customer due diligence, Recommendation 16 on the Travel Rule, and the 2019 updates that brought virtual asset service providers (VASPs) into scope, set the baseline that national supervisors then implement. In Pakistan, the Financial Monitoring Unit (FMU) receives suspicious transaction reports (STRs) and operates within the FATF-aligned framework; under the Virtual Assets Act 2026, the Pakistan Virtual Asset Regulatory Authority (PVARA) extends that regime to VASPs explicitly. In the Gulf, the Emirati, Saudi and Bahraini regulators each operate AML regimes that align to FATF but diverge on implementation detail. A fintech operating across multiple jurisdictions cannot assume a single configuration will satisfy every supervisor.

The consequence for infrastructure is that fintechs need KYC and AML stacks that are modular, multi-tenant where the business is multi-brand, configurable by jurisdiction, auditable end-to-end and fast enough not to kill conversion on the onboarding funnel. That is the infrastructure problem this guide is about.

The first architectural decision is whether to integrate a single KYC vendor end-to-end or to orchestrate multiple providers behind a unified verification layer. Each approach has trade-offs that matter at scale.

The single-provider approach is attractive early. Vendors such as Sumsub, Onfido, Jumio, Persona and Veriff offer integrated stacks that combine document capture, biometric liveness, sanctions and PEP screening, and ongoing monitoring behind a single API and a single contract. For a pre-seed fintech with one jurisdiction and a narrow product, wiring up a single provider is the fastest route to a live onboarding funnel. It also concentrates the compliance evidence trail with one counterparty, which is easier to demonstrate at a Series A due diligence.

The single-provider approach starts to fray in three situations. The first is geographic expansion: few providers offer the same quality of coverage across South Asia, the Gulf, Europe and North America, and a firm that locks into one vendor will find itself compromising on verification quality in some corridors to preserve integration simplicity in others. The second is specialised verification requirements: Pakistan's NADRA-backed verification, for example, is served best by local providers such as Verisys, and no global vendor currently replaces that capability. The third is cost and leverage: single-vendor pricing escalates sharply once volumes become material, and a firm without a second integrated provider has no negotiating position at renewal.

The multi-provider approach orchestrates several specialised vendors behind an internal verification layer that routes a verification request to the right provider based on jurisdiction, product tier, risk signal or cost target. Sumsub might handle primary identity verification for Europe; Verisys handles Pakistan through NADRA; Orbit or a local vendor handles corporate KYC; a specialist sanctions screener such as ComplyAdvantage or Refinitiv World-Check runs name-screening. The verification layer produces a single normalised verification record that feeds downstream compliance systems.

The cost of multi-provider orchestration is the orchestration layer itself. It has to handle provider-specific payloads, normalise outcomes into a consistent verification record, manage provider outages with graceful fallback, track cost per verification to enable routing optimisation and preserve an audit trail that a supervisor can follow. Firms building this layer typically build it as an internal service that other product teams call through a stable API; the product teams should never need to know which vendor processed a given verification. Bridge's identity platform is built around this pattern, treating KYC providers as pluggable backends rather than as the system of record.

Risk scoring has been part of AML for decades. The traditional approach is a rules engine that evaluates a customer or transaction against a set of policy-defined thresholds — country of residence, source of funds, transaction value, counterparty type — and produces a risk rating. The strengths of rules engines are transparency (a rule fires or does not), auditability and regulator comfort. The weaknesses are brittleness (rules do not adapt to patterns the rule-writer did not anticipate) and a high false-positive rate that drains compliance analyst time.

AI risk scoring complements rules rather than replacing them. A well-designed system runs a rules engine for mandatory controls and regulatory thresholds, and runs machine-learning models alongside for pattern-level risk signals — unusual transaction velocity, counterparty clustering that suggests layering, behavioural anomalies relative to the customer's stated profile, or document authenticity signals that traditional OCR pipelines miss. The models produce a continuous score, typically on a 0-to-100 scale, that feeds into the overall risk rating and supports analyst prioritisation.

The design questions that matter for AI risk scoring are model explainability (a supervisor will ask how a given customer came to be rated as high risk, and the answer has to be defensible), training-data provenance (models trained on biased or narrow data will discriminate in ways that produce both unfair customer outcomes and conduct-risk exposure), drift monitoring (financial-crime patterns evolve, and a model trained two years ago is decaying), and human-in-the-loop design (high-risk flags should produce analyst review, not automated action, for anything that could materially affect a customer).

Firms should be cautious about vendor claims that AI models reduce false positives by specific percentages. Vendor-supplied figures typically reflect performance on their training set, which may bear limited resemblance to the firm's own customer base. The honest evaluation is a parallel-run of the vendor model against the firm's existing rules output, on real customer data, over a period long enough to see both steady-state behaviour and edge cases. Our dedicated post on AI risk scoring for AML covers model design and evaluation in more detail.

Not every customer needs the same verification depth. A customer making a PKR 5,000 local transfer does not need the same due diligence as a customer opening a corporate treasury account with a seven-figure funding flow. Tier-based verification is the architectural response: a verification model with multiple tiers, each gated by product scope and transaction limits, each corresponding to a different depth and cost of verification.

A typical three-tier model looks like this. Basic tier verification captures core identity information — full name, date of birth, national identity reference, contact details — and performs a sanctions and PEP screening against the provided attributes. The customer is granted low transaction limits and a narrow product scope: inbound fiat, small outbound, no cross-border, no virtual asset activity above the Travel Rule threshold. Standard tier adds documentary verification (identity document capture, liveness check) and proof-of-address, lifting limits and opening most products. Full tier adds source-of-funds verification, enhanced due diligence for higher-risk attributes and, for corporate customers, ultimate beneficial ownership mapping, lifting limits to institutional thresholds and unlocking the full product.

The tier design has to match the product roadmap and the regulatory perimeter. Regulators generally permit tiered onboarding provided that the tier limits are consistent with the risk profile and that customers who exceed a tier's limit are required to upgrade before further activity. Firms that set tier limits too generously, or that fail to enforce the upgrade gate, produce supervisory findings that are both technically-driven and hard to remediate after the fact.

Tier design also interacts with conversion. Every additional verification step costs a measurable share of funnel conversion. The right tier design gives a customer immediate access to low-risk activity while progressive verification happens in the background or as a just-in-time gate when the customer attempts an activity that requires it. Our KYC-as-a-service offering implements this pattern natively, with tier thresholds configurable per jurisdiction and per product.

For any fintech that touches virtual assets, Travel Rule integration is a non-optional part of the compliance stack. FATF Recommendation 16 requires that originator and beneficiary information accompany virtual asset transfers between VASPs above a threshold that most jurisdictions implement as USD 1,000 or the local-currency equivalent. The data set typically includes originator name, originator account or wallet reference, originator physical address or national identity reference, beneficiary name and beneficiary account or wallet reference, though the exact fields vary by jurisdiction.

The technical challenge is that the Travel Rule is a counterparty protocol, not just a reporting obligation. A firm has to identify which counterparty wallet belongs to another VASP (as opposed to an unhosted wallet), exchange the required data with that counterparty in a standardised format, handle the cases where the counterparty is not participating, and do all of this without blocking transfers that should not be blocked.

Several protocols have emerged — Notabene, Sumsub Travel Rule, Veriscope, the TRP protocol from the Travel Rule Protocol working group, OpenVASP — each with its own message format and VASP directory. A production fintech typically integrates at least two protocols to maximise counterparty reach, with a Travel Rule orchestration layer that abstracts the protocol choice from the rest of the stack. Our Travel Rule platform is built on this principle.

The deeper architectural question is where the Travel Rule enforcement sits. Many firms implement it as a pre-transaction compliance gate: the transfer is assembled, the compliance layer checks Travel Rule status, and the transfer is then submitted to the chain. That works, but it leaves a gap between the compliance decision and the on-chain action. Emerging patterns — transfer hooks on Solana's Token-2022 standard, compliance-aware flows on Corda — embed the Travel Rule check at the protocol level, so the on-chain action itself cannot complete without the compliance evidence. We explore that pattern in our compliance-native fintech API guide.

KYC and AML infrastructure has a cost structure that is poorly understood at the planning stage and painfully understood once scale arrives.

Per-verification costs from external providers typically range from under one US dollar for basic sanctions screening to ten US dollars or more for full identity verification with liveness and document authentication. Ongoing monitoring — periodic re-screening against updated sanctions lists, adverse media monitoring — is usually priced per customer per year. Travel Rule protocol access carries either per-transaction fees or annual platform fees depending on the vendor. AI risk-scoring vendors typically price on transaction volume.

The hidden costs are analyst time and supervisory time. A compliance analyst reviewing a high-risk flag can spend anywhere from fifteen minutes to two hours on a single case, depending on the complexity. A firm running a 95 per cent false-positive rate on its monitoring system is paying for analyst time to clear alerts that never needed to be raised. Supervisory time — the time a compliance leadership team spends responding to information requests, inspection findings and policy updates — scales with the quality of the underlying infrastructure. Poor infrastructure produces more supervisory work, not less.

A useful cost framework is to separate fixed platform costs (integration, orchestration layer, audit and reporting infrastructure) from variable per-transaction costs (verification fees, screening fees, Travel Rule fees) and from operational costs (analyst headcount, supervisory engagement). The total cost per onboarded customer and per monitored transaction, rolled up across all three layers, is the number that should appear in product pricing discussions — not the headline vendor fee.

The build-versus-buy question in KYC and AML infrastructure has the same shape as in most regulated-fintech decisions. Buying is faster to market and shifts some operational responsibility to the vendor; building is slower but produces infrastructure that the firm fully controls and that can be evolved in lock-step with the product.

Most fintechs should buy the components and build the orchestration. The specific verification providers — document capture, biometric liveness, sanctions screening, corporate KYC — are commodities at this point, and building any of them from scratch is rarely a good use of engineering capital. The orchestration layer that sits on top — the verification state machine, the tier enforcement, the risk scoring integration, the audit trail, the analyst tooling — is where firms should own the code, because it is where the product and the compliance policy meet.

An emerging pattern is compliance-as-infrastructure platforms that offer the orchestration layer as a service, with pluggable verification providers underneath. This shortens the build timeline without losing configurability. Bridge Intelligence operates this model: customers plug into our identity platform and inherit the orchestration, audit and tier design, while retaining the ability to configure providers and policies to their jurisdiction and product. For firms building in Pakistan, this includes integrated NADRA-backed verification and Travel Rule enforcement out of the box.

Firms that opt to build everything in-house should budget not only for initial development but for a dedicated engineering team in steady state. Regulatory changes, vendor API updates, new jurisdictions and new products all require sustained investment. A compliance platform is not a project; it is a product with a ten-year roadmap.

A KYC and AML stack will, at some point, be inspected. The inspection may be routine, triggered by a specific supervisory concern, or triggered by an incident. The design criterion that matters most in any of those cases is whether the stack can produce, on demand, a defensible answer to a specific question about a specific customer or a specific transaction.

Defensible means that for any customer in the system, the firm can show when the verification occurred, which provider processed it, what data was captured, what risk rating was assigned, what rules fired, what analyst actions were taken and what policy versions were in force at the time. For any transaction, the firm can show what screening was performed, what Travel Rule exchange occurred, what rules fired and what outcome was produced. This is an audit-trail problem, not a policy problem, and it has to be designed in from the start. Retrofitting an audit trail to a system that was not designed to produce one is a multi-quarter project that most firms undertake only after a supervisory request forces it.

The architecture that produces a defensible audit trail is event-sourced: every verification action, every risk decision, every analyst step is recorded as an immutable event, and the current state of any customer or transaction is derivable from the event log. Event-sourced systems are harder to design than database-of-record systems, but they produce audit trails that supervisors find credible without further work. Bridge's identity and compliance platform is built on this pattern by default.

The framing that unlocks good KYC and AML infrastructure is to treat it as product infrastructure rather than as a compliance burden. Every fintech decision — which products to offer, which jurisdictions to enter, which customer segments to serve, which chains to support — is constrained or enabled by what the compliance stack can do. Firms that build compliance into the product architecture produce faster onboarding, better conversion, lower operating cost and better supervisory outcomes simultaneously. Firms that bolt compliance on afterwards produce the opposite.

The building blocks covered in this guide — multi-provider verification, AI risk scoring, tier-based onboarding, Travel Rule integration, event-sourced audit trails — are not exotic. They are the current state of practice for serious regulated fintechs. The work is in combining them into a coherent operating model and in owning that operating model as the regulated perimeter evolves.

Bridge Intelligence operates KYC, AML and Travel Rule infrastructure across its regulated footprint in Pakistan and the Gulf, and offers the same platform to fintechs, banks and VASPs as KYC-as-a-service, NADRA-backed verification and Travel Rule. To discuss your architecture, reach out via our contact page or explore the build documentation.