Customer Risk Profiling
One authoritative risk state per customer, updated in real time. Every transition is triggered by an event, approved by someone accountable, and written to an immutable trail.
Risk signals scattered across systems produce contradictions
Risk signals are scattered: a screening hit lives in one system, a monitoring alert in another, KYC status in a third. Without a single authoritative state, two parts of the same fintech can hold contradictory views of the same customer — and no one can reconstruct why a customer was treated the way they were.
Without a unified risk state
- ✗
Screening result sits in the vendor dashboard, not connected to payment decisions
- ✗
Monitoring alert raises a flag, but the payment handler doesn't know
- ✗
KYC tier stored in onboarding system, not enforced at transaction time
- ✗
Two engineers query different systems and get different risk answers for the same customer
- ✗
Evidence reconstruction takes days when a regulator asks why a transaction processed
With Fintegrity's unified risk state
- ✓
One state per customer — read by the Decision API before every transaction
- ✓
Screening hits, monitoring alerts and KYC events all converge into the same state machine
- ✓
Every state transition recorded with its trigger, approver (where required) and evidence
- ✓
Any query returns the same answer — the authoritative current state
- ✓
Full history of how a customer's risk evolved reconstructable on demand
Six states. Event-driven transitions. Every move evidenced.
Fintegrity maintains a single risk state per customer, driven by a compliance state machine. The state moves only through defined, event-driven transitions — and each transition records what triggered it, who approved it (where approval is required), and what evidence was used.
What each state means for a transaction
The risk state is read by the Decision API before every transaction. It is not a report you look at after the fact — it is enforced at the moment of every call.
Onboarding started
Verification has been initiated but is not yet complete. Transactions may be limited to a minimum tier until verification passes.
Verified and in good standing
The customer is fully verified. Transactions proceed through full rule evaluation with no additional restrictions from risk state.
Verification due for refresh
Verification has expired or reached its scheduled refresh date. Elevated monitoring applies until refresh completes.
Flagged for compliance review
Triggered by a screening hit, monitoring alert, or manual escalation. A case is open; an analyst is investigating.
Limited access pending resolution
High-risk case outcome. Access is restricted while the investigation or remediation is in progress.
Barred from transacting
All transactions return BLOCKED before any rules run. No amount or type of transaction can proceed while this state is active.
Every state change is an evidence event
A manual override requires a reason, the approver's identity, and supporting evidence — no silent state changes. Automatic transitions (from screening hits or monitoring alerts) record the triggering event directly in the transition record. The result is a full chronological history of a customer's risk lifecycle, reconstructable on demand.
What caused the change
Every transition records the triggering event — a screening match, a monitoring alert, a case outcome, KYC expiry, or a manual action.
Who authorised it
State changes that require manual action are attributed to a named analyst. Automated transitions are attributed to the system event that triggered them.
What supported the decision
Supporting evidence — case reference, screening result, rule that fired — is linked to each transition and retained in the immutable audit ledger.
The profile is enforced, not just recorded
Because the risk state is read by the Decision API before money moves, the profile isn't a report you look at after the fact — it's enforced at the moment of every transaction.
A BLOCKED customer gets a hard stop before any rules run. It doesn't matter what device they use, what channel they try, or how small the transaction amount is — the state check happens first, and it's deterministic.
And because every transition is evidenced, the full history of how a customer's risk evolved is reconstructable on demand — for regulators, auditors, or your own compliance team.
The risk state is the first check in every decision call. BLOCKED customers get a hard stop before any rule evaluation runs.
Monitoring alerts are one of the event triggers that can transition a customer's risk state — connecting detection to enforcement automatically.
Case outcomes (cleared or adverse) are the mechanism by which a RISK_REVIEW_REQUIRED state resolves — back to KYC_OK or forward to RESTRICTED.
See how Fintegrity evaluates transactions in real time
We'll walk through the risk state machine live — from a screening hit triggering a state change, to a case outcome resolving it, to the evidence trail that makes every decision defensible.