Skip to content
Parikh AdvisoryLogic Before Code

FinTech & Regulated Products

KYC Is a Workflow, Not Just an Identity Check

Communicate the actual state of customer review.

Verified identity is not a complete workflow.Communicate the actual state of customer review. Collect evidence relevant to the customer Verify and assess under applicable policy Clear, refer or request further information. Ownership question open → communicate pending reviewOne check passed. One question remains.Identity ✓Ownership reviewPendingCommunicate the actual state
Verified identity is not a complete workflow.Original conceptual illustration · not a client case

The decision in a glance

Verified identity is not a complete workflow.

KYC is a continuing evidence and decision workflow, not one upload screen. Scope depends on jurisdiction, product, customer type and activity; identity verification is just one control among due diligence, screening, risk classification, enhanced review and ongoing monitoring. Define each state, evidence, change trigger and responsible reviewer. Marketing copy must not mistake vendor capabilities for legal compliance.

Follow the visual explanation ↓

The business situations in this article are fictional illustrations, not accounts of Parikh Advisory client engagements.

A customer uploads identification and sees “verified.” Their account remains unavailable because an ownership question is still under review. The screen suggests the journey is complete; operations has a different state. That mismatch is a product and control problem. In financial services, customer due diligence can involve identity, beneficial ownership, purpose of relationship and ongoing scrutiny; the exact duties depend on the jurisdiction, activity and risk profile.

Map the states people actually use

A single pass/fail field cannot express submitted, incomplete, awaiting external data, under manual review, approved with conditions, rejected, or due for periodic review. Define which transitions are automatic, which need an authorized reviewer, and which can be reversed. Keep a dated record of evidence, rule version, decision maker and reason. The product state shown to the customer can be simpler than the internal state, but it must not promise access that has not been granted.

Visual explanation · 01

Follow the situation

  1. Collect evidence relevant to the customer
  2. Verify and assess under applicable policy
  3. Clear, refer or request further information
  4. Ownership question open → communicate pending review
Communicate the actual state of customer review. The exception path matters as much as the expected route.Illustrative framework · no client data

Design the exception path first

Suppose an individual passes document verification but a business customer’s ownership information is unclear. Who asks for more information? What can the customer do while waiting? How is a false match escalated? When can a reviewer override an automated result, and who checks that override? These cases determine staffing, turnaround and auditability. A smooth upload screen alone does not settle them.

Protect the customer without exposing controls

Tell users what they need to provide, the current broad status and how to get help. Avoid disclosing sensitive screening logic that could enable evasion. Make requests specific enough to act on and prevent repeated document requests caused by disconnected teams. Define retention and access with qualified legal and compliance owners. Product designers should not invent a universal retention period or approval rule from a generic template.

Visual explanation · 02

Compare the next moves

  1. Evidence: Collect the information the applicable review needs.
  2. Decision: Give unresolved questions an authorized owner.
  3. Lifecycle: Define change triggers and subsequent review.
Use these choices to frame the next commitment. There is no automatic winner.Illustrative framework · no client data

Treat approval as a continuing relationship

Changes in ownership, activity or risk may require further review after onboarding. The FATF recommendations describe ongoing due diligence and scrutiny of transactions as part of the customer relationship. This is an international standard; local law and the applicable regulator determine implementation. Build a workflow that can request updated evidence, assign review, record decisions and communicate restrictions appropriately. Test it with the compliance owner before using live customer data.

A decision to take into the next meeting

Bring one actual case, name its owner and decide what evidence would justify the next investment. If the evidence is missing, make the smallest useful test the next action. Record the choice and the date to review it.

Source note: FATF Recommendations (updated June 2026). The example is illustrative; the source informs the method or control discussed, not the imagined business.

Sources & scope

Related primary reading is provided below. The decision framework and fictional examples are Parikh Advisory’s analysis; these references do not establish that the illustrated events occurred.

  1. FATF Recommendations: customer due diligence and ongoing monitoringFinancial Action Task Force

Educational product and operating analysis. Applicable legal, financial, risk and compliance requirements need qualified review for the specific activity and jurisdiction. This article does not certify launch readiness or compliance.