DEV Community

Cover image for KYC Should Not End at Onboarding: Designing Event-Driven Identity Reverification
Vaibhav Shakya
Vaibhav Shakya

Posted on

KYC Should Not End at Onboarding: Designing Event-Driven Identity Reverification

#architecture #fintech #backend #security

KYC Should Not End at Onboarding: Designing Event-Driven Identity Reverification

Most KYC systems are designed around one successful moment:

KYC_PENDING
    ↓
KYC_VERIFIED
Enter fullscreen mode Exit fullscreen mode

After that, VERIFIED often becomes a long-lived attribute copied across applications and downstream services.

But identity is not static.

Documents expire. Business information changes. Risk classifications move. Screening results change. Customer information becomes stale.

The architectural question should therefore evolve from:

Did this customer pass KYC?

to:

Given what we know now, how much confidence should we still place in the customer's identity and due-diligence state?

That makes KYC a lifecycle problem, not just an onboarding workflow.

The Problem

A more realistic identity state machine may allow:

VERIFIED
    ↓
REVIEW_REQUIRED
    ↓
REVERIFICATION_PENDING
    ↓
VERIFIED
Enter fullscreen mode Exit fullscreen mode

Moving a customer back into review does not mean the original verification was wrong.

It means the system received new information, reached a scheduled review point, or applied a policy that requires identity confidence to be reassessed.

The important architectural separation is:

Event
  ↓
Policy Evaluation
  ↓
Identity State
  ↓
Workflow
  ↓
Eligibility
Enter fullscreen mode Exit fullscreen mode

Events describe what changed. Policy decides what that change means.

A profile service, for example, should preferably emit:

ADDRESS_CHANGED
Enter fullscreen mode Exit fullscreen mode

rather than:

CUSTOMER_MUST_REPEAT_KYC
Enter fullscreen mode Exit fullscreen mode

The producer knows that reality changed. It should not necessarily own the compliance consequence.

Where It Gets Difficult

Event-driven KYC introduces several distributed-system concerns.

Duplicate processing

A broker may redeliver an event after a failure.

Without idempotency, one identity change could create multiple workflows, notifications, compliance cases, or provider requests.

Stable event IDs and database-level uniqueness constraints are therefore important.

Out-of-order events

Suppose:

10:01 — Address changed to B
10:02 — Address changed to C
Enter fullscreen mode Exit fullscreen mode

If the identity service receives C before B, blindly applying arrival order can restore stale data.

Versions, timestamps, aggregate sequencing, and transition validation may be required where ordering matters.

Stale mobile state

Android or iOS may still display:

KYC = VERIFIED
Enter fullscreen mode Exit fullscreen mode

after the backend has moved the customer into reverification.

The mobile application should render the workflow, but sensitive authorization should remain server-side.

Cached UI state must never become the authority for whether a settlement, payment, or another protected action is allowed.

Provider uncertainty

An external verification provider may successfully process a request while the local call times out.

The correct state may temporarily be neither success nor failure.

Systems need explicit pending or uncertain states, retry-safe integration where possible, and reconciliation.

Architectural Direction

A practical design separates responsibilities:

  • Event producers report relevant changes.
  • A policy engine determines whether reevaluation is required.
  • The identity service owns authoritative lifecycle state.
  • Reverification runs as a resumable workflow.
  • External providers produce evidence rather than directly controlling final eligibility.
  • Backend authorization checks current eligibility for sensitive operations.
  • Reconciliation repairs cases where asynchronous processing was missed or remained incomplete.

For larger systems, an eligibility projection can then be consumed by payments, settlements, lending, or merchant services.

That improves autonomy, but it also introduces eventual-consistency decisions.

The architecture must explicitly decide where stale identity state is acceptable and where it is not.

The Takeaway

KYC should not be treated as a gate a customer crosses once.

It is better modeled as a maintainable identity state whose confidence can change when customer information, evidence, risk, or policy changes.

The goal is also not to force full KYC after every signal.

It is to support proportionate reverification: evaluate what changed, apply policy, request only the required verification, and enforce the resulting eligibility from the backend.

Want the deeper architectural breakdown, implementation considerations, failure scenarios, and full reasoning?

Read the full article on Medium

#KYC #FinTechArchitecture #IdentityVerification #SecurityArchitecture

Top comments (0)