KYC, KYB and transaction-monitoring architecture

A financial-crime compliance architecture is more than a set of tools bolted together. Know-your-customer (KYC), know-your-business (KYB), sanctions and PEP screening, fraud detection and transaction monitoring each solve a different problem, and case management ties them together into something auditable. Vendors supply capabilities; they do not set your risk appetite or absorb your legal responsibility. This guide describes how to arrange these components into a coherent lifecycle so that detection, investigation and evidence work as one system.

Legal and regulatory status was reviewed on 7 July 2026.

Lifecycle architecture

Think in terms of a customer lifecycle rather than isolated checks: onboarding, ongoing monitoring, periodic and event-driven review, and offboarding. Each stage feeds the next — the risk assessment produced at onboarding should shape monitoring intensity, and monitoring outcomes should feed back into the risk picture. The EU anti-money-laundering framework is being consolidated: the AML Regulation (EU) 2024/1624 will mainly apply from 10 July 2027, so parts of it are a preparation obligation rather than a currently applicable rulebook 1. Design the architecture so it can evolve rather than assuming any single fixed rule set.

Customer-risk assessment

A customer-risk assessment scores the money-laundering and terrorist-financing risk of each customer using factors such as customer type, geography, products used and expected activity. This score drives the depth of due diligence and the intensity of monitoring. It is the institution’s decision, informed by its own risk appetite — a vendor’s default model is a starting point, not a substitute for your own methodology.

Individual identity verification

KYC for individuals establishes that a person is who they claim to be, typically combining document verification, biometric checks and database validation. The strength of verification should be proportionate to risk. Collect what you need to verify identity and no more, so the design aligns with data-minimisation expectations discussed below.

Business verification

KYB establishes the identity and legitimacy of a business customer: legal existence, registration, structure, directors and authorised signatories. Business onboarding is more complex than individual onboarding because it involves documents from registries, corporate structures and roles. Plan for manual review paths where automated data is incomplete.

Beneficial-ownership identification

Beneficial-ownership identification determines the natural persons who ultimately own or control a business customer. This can require unwinding layered structures and cross-checking registry and customer-provided data. Record how ownership was established and the evidence relied upon, because this is frequently examined.

Document, biometric and database checks

Verification methods include document authentication, biometric liveness and face matching, and checks against authoritative databases. Each method has different accuracy, cost and friction characteristics, and each can fail for legitimate customers. Combine methods according to risk and provide a fallback route so genuine customers are not permanently blocked by a single failed check.

Sanctions and PEP screening

Screening checks customers (and relevant connected parties) against sanctions lists and politically exposed person (PEP) data. Sanctions screening is about legal restrictions; PEP screening flags people whose position warrants enhanced due diligence — not automatic exclusion. The mechanics of matching, thresholds and triage are covered in sanctions, PEP and adverse-media screening architecture.

Adverse-media screening

Adverse-media screening surfaces negative news about a customer or connected party. Adverse media is a signal to investigate, not proof of wrongdoing. Treat hits as inputs to a documented review, and be careful about the quality and relevance of sources so the process is fair and defensible.

Device, behavioural and payment-fraud signals

Fraud controls use device, behavioural and payment signals to detect account takeover, synthetic identity and payment fraud. Fraud detection and AML monitoring overlap but are not identical — fraud is often faster and loss-focused, AML is pattern- and reporting-focused. Design them to share signals where useful while keeping their distinct purposes clear, as in build a fraud and transaction-monitoring stack.

Transaction-monitoring data inputs

Transaction monitoring is only as good as its inputs: transaction records, counterparties, customer profile, risk score, and reference data. Missing or low-quality data produces both missed activity and noise. Map every input the monitoring layer needs and confirm its source, freshness and reliability before tuning any rule.

Rules, scenarios and model-based detection

Detection combines deterministic rules and scenarios (thresholds, typologies) with model-based approaches (statistical or machine-learning scoring). Rules are transparent and explainable; models can catch subtler patterns but need governance and explainability. Most architectures use both. Whichever you use, you must be able to explain why an alert fired.

Threshold governance and tuning

Thresholds determine alert volume and quality. Setting them too tight floods investigators; too loose misses activity. Threshold changes should follow a governed process with documented rationale, testing and approval — not ad-hoc edits. Retain records of what changed, when and why.

Ongoing monitoring and refresh

Customer risk is not static. Ongoing monitoring watches activity against expectations, and periodic or event-driven refresh updates customer information and risk scores over time. A relationship that was low risk at onboarding can change; build triggers (behaviour changes, new information, time elapsed) that prompt reassessment.

Case management

Case management is the workbench where alerts become investigations: assembling data, recording analyst decisions, tracking status, and linking related alerts. Good case management turns detection into defensible outcomes. Weak case management undermines even excellent detection because decisions cannot be evidenced.

Escalation and suspicious-activity reporting

Investigations may escalate to a decision on whether to file a report with the relevant authority. Define escalation paths, decision ownership and timeliness. The institution — not the vendor — is responsible for reporting decisions and for meeting the obligations set out in the applicable national framework transposing the AML directive 2.

Audit trail and evidence

Every decision — onboarding approval, alert disposition, threshold change, reporting decision — needs an audit trail with who, what, when and why. Regulators and, increasingly, coordinated EU-level supervision expect to see this evidence; the AML Authority is established to strengthen supervision and coordination 3. Design auditability in from the start rather than reconstructing it later.

Orchestration and decision engines

An orchestration or decision layer coordinates the components: routing a customer through the right checks, combining results, applying policy, and producing a decision or a case. This layer is where your policy becomes executable. Keeping it configurable (rather than hard-coded across vendors) makes the whole architecture easier to change and audit.

Build versus buy

You can build components in-house, buy specialised vendors, or use an orchestration platform over multiple vendors. Building gives control but demands sustained investment; buying accelerates delivery but adds vendor dependency. Most fintechs blend the two. Decide per component based on how core it is, how fast it must evolve, and your team’s capacity.

Vendor evaluation criteria

Evaluate vendors on detection quality, explainability, data coverage, integration, configurability, auditability, data-protection posture and operational support. A slick demo is not evidence of production performance. Test with representative data and confirm you can explain and audit the vendor’s outputs — see fintech provider due diligence and RFP and DORA, fintech vendor risk and outsourcing.

Data protection, minimisation and retention

Financial-crime processing handles sensitive personal data, so it must respect data-protection principles including lawfulness, data minimisation and defined retention, under the General Data Protection Regulation 4. Collect only what you need, retain it only as long as justified, and document the basis for processing. Data-protection and AML obligations must be reconciled deliberately, not treated as opposites.

Architecture diagram

The following text diagram shows how components connect:

Stage	Component	Feeds into
Onboarding	Identity / business verification	Risk assessment
Onboarding	Sanctions / PEP / adverse-media screening	Case management
Onboarding	Customer-risk assessment	Monitoring intensity
Ongoing	Transaction monitoring (rules + models)	Alerts
Ongoing	Fraud signals	Alerts
Ongoing	Screening rescreening	Alerts
Investigation	Case management	Escalation / reporting
All stages	Orchestration + audit trail	Every component

Responsibility matrix

Function	Typical owner	Accountable party
Risk appetite and methodology	You	You (regulated entity)
Identity / business verification	Vendor tooling	You
Screening data and matching	Vendor	You (for decisions)
Transaction monitoring rules	You + vendor	You
Threshold governance	You	You
Case investigation	You / outsourced ops	You
Reporting decisions	You	You
Data protection	You	You (as controller)

Common control gaps

• Adopting a vendor’s default risk model as if it were your risk appetite.
• Poor data inputs quietly degrading transaction monitoring.
• Ungoverned, undocumented threshold changes.
• No event-driven refresh, so stale risk scores persist.
• Weak case management that cannot evidence decisions.
• Treating adverse media as proof rather than a signal to investigate.
• Ignoring data-minimisation and retention until a data-protection review forces it.

Questions to ask providers

• How does your tool support our own risk methodology, rather than imposing a default?
• What data inputs does monitoring require, and how do you handle gaps?
• Do you use rules, models or both, and how are outputs explained?
• How are threshold changes governed, tested and recorded?
• How does case management capture decisions and produce an audit trail?
• How do you support event-driven refresh and ongoing monitoring?
• What is your data-protection posture on minimisation and retention?
• How do you help us demonstrate auditability to supervisors?

What this does not cover

This guide does not provide legal advice, does not set your risk appetite, and does not confirm that any architecture is compliant for your institution. It does not describe the AML Regulation as already fully applicable, since it mainly applies from 10 July 2027 1. It complements — but does not replace — advice tailored to your entity, products and jurisdictions.

• Customer-risk methodology defined by you, not the vendor
• Identity, business and beneficial-ownership checks mapped to risk
• Screening (sanctions/PEP/adverse media) integrated with case management
• Transaction-monitoring data inputs mapped and quality-checked
• Rules, scenarios and any models documented and explainable
• Threshold governance process with rationale and approval
• Ongoing and event-driven refresh triggers defined
• Case management captures decisions and full audit trail
• Escalation and reporting ownership assigned to the institution
• Data minimisation and retention designed in and documented

FAQ

Are KYC, KYB and transaction monitoring the same thing?

No. KYC verifies individuals, KYB verifies businesses, and transaction monitoring watches activity for suspicious patterns over time. They are complementary components of one architecture, not interchangeable.

Does buying a vendor tool transfer our AML responsibility?

No. Vendor tools provide capabilities, but the regulated institution remains responsible for its risk appetite, decisions and reporting. The obligations sit with you regardless of which tools you use.

Is the EU AML Regulation already fully in force?

The AML Regulation (EU) 2024/1624 will mainly apply from 10 July 2027 1. Until then, treat parts of it as a preparation obligation and distinguish it from currently applicable national rules transposing the AML directive 2.

How do fraud detection and AML monitoring differ?

Fraud detection is typically faster and loss-focused (account takeover, payment fraud), while AML monitoring is pattern- and reporting-focused. They can share signals but serve different purposes and should stay distinct.

How do data-protection rules affect this architecture?

Financial-crime processing must respect data-minimisation and retention principles under the General Data Protection Regulation 4. Collect only what you need, retain it only as long as justified, and document the basis for processing.