Reusable KYC Across Wallets and Payment Providers

TL;DR

• Reusable KYC transfers verified identity inputs with user consent. It does not transfer a universal compliance approval.
• The receiving institution must check credential freshness, expiry, and revocation before relying on prior verification.
• A policy layer must compare transferred inputs with the institution’s jurisdiction, risk, product, and sanctions requirements.
• Identified gaps should trigger targeted KYC and AML checks through existing verification and screening providers.
• Audit evidence should prove that covered checks ran against the applicable policy. It cannot prove that every external input was true.
• This architecture serves wallets and payment providers onboarding users who completed KYC on another platform.

Why prior KYC requires a new compliance decision

A prior KYC decision cannot serve as universal compliance approval. The institution that performed the verification applied its own policy, risk appetite, and available data at a specific time. A receiving wallet may operate under different legal obligations or offer a product with a higher risk profile.

Prior verification provides evidence for a new decision. The receiving institution must determine whether that evidence satisfies its current requirements before approving the customer or transaction. A document delivered to escrow can support a release decision, but the escrow agent still checks the current release conditions before funds move. A reusable identity credential should work the same way. The credential supplies evidence, while the receiving institution decides whether its current policy permits the transaction.

Credential age can make previously verified information unsuitable for a current decision. An identity document can expire, and an issuing institution can revoke a credential after detecting fraud. A customer’s sanctions or politically exposed person status can also change after the original screening. A wallet that imports the earlier result without checking freshness may rely on information that no longer supports approval.

Jurisdictional and product differences create separate gaps. A credential issued for a low-value domestic wallet may not cover the checks required for a cross-border payment product. The prior review may confirm a person’s identity but omit source-of-funds evidence. Corporate onboarding may require beneficial ownership information that a consumer credential never collected.

Blanket acceptance also weakens auditability. A prior credential shows what another institution verified, but it does not show why the receiving institution considered its own requirements satisfied. Without a fresh policy evaluation, an auditor cannot reliably connect the reused inputs to the transaction decision. The receiving institution should treat prior verification as evidence to evaluate rather than approval to inherit.

What reusable KYC actually means

Reusable KYC is the transfer, with the user's authorization, of previously verified identity attributes and supporting evidence between institutions. The receiving institution reuses those inputs instead of collecting every document again. The transfer does not create mutual recognition of the original institution’s compliance decision.

Identity verification confirms specific claims about a person. A provider may validate a legal name against an identity document and bind the document to its holder through a biometric match. Transferable evidence can include verified attributes, the verification method, the issuer, and the verification date.

A compliance determination applies an institution’s own policy to those identity inputs. The receiving institution must assess jurisdictional rules and product risk. It must also evaluate current sanctions status and other AML controls. A prior risk score reflects another institution’s policy and point in time, so it cannot serve as universal approval.

User consent defines which verified attributes the receiving institution may access and for what purpose. Consent authorizes disclosure, but it does not establish credential freshness or policy fit.

A wallet or payment provider should therefore treat reusable identity as evidence available for evaluation. The institution still decides whether the evidence satisfies its KYC compliance requirements and which additional checks remain necessary.

Architecture for evaluating reused identity

A reusable KYC architecture should convert prior verification into inputs for a new compliance decision. The receiving institution first obtains consent for identity sharing, then checks credential freshness and revocation status. Its compliance engine compares the available inputs with institution-specific policy and runs incremental KYC or AML checks for any gaps. The institution then evaluates the transaction before execution and produces independently verifiable evidence of the covered policy checks. Each stage acts as a control point rather than an administrative formality.

Consented identity sharing between institutions

A receiving institution should request only the verified attributes required by its policy. The user reviews that request and authorizes the issuing institution to release the named fields for a defined purpose. Selective disclosure credentials or signed API responses can carry those attributes without giving the receiver unrestricted access to the user’s identity file.

The transferred package should include evidence that the issuer verified each disclosed attribute. Credential metadata should identify the issuer and verification method. Separate metadata should record issuance time, expiration, and current status. The receiving institution uses those details to authenticate the source and determine which checks remain valid.

The receiving institution should avoid requesting raw identity documents unless its policy or legal obligations require them. Document images expose more personal data than most receiving institutions need. A transferred risk score is useful only when the receiving institution can assess its criteria, context, and relevance to its own policy. Reusing a score without its underlying criteria can misrepresent what the issuer assessed.

Granular consent limits both disclosure and subsequent use. A consent record should bind the authorized attributes to the named recipient, stated purpose, and permitted time window. The record should also capture the credential version and authorization time. A signature or equivalent authenticated approval can help an auditor check which user authorized the transfer. The institution also needs records showing whether later use remained within the authorized scope.

Consent provides permission to share identity inputs. The receiving institution still applies its own KYC compliance and AML controls before approving the customer or transaction.

Checking credential freshness and revocation

A verified identity credential remains cryptographically authentic even when its claims no longer satisfy current policy. Addresses change, documents expire, and issuers discover fraud after issuance. The receiving institution should therefore apply its own maximum age to each credential or attribute. Higher-risk products and transactions may require shorter expiry windows.

Re-verification triggers should reflect changes that affect identity confidence or policy eligibility. Common triggers include an expired identity document, inconsistent account details, a material change in customer information, or a transaction outside the expected risk profile. A credential should also require review when the receiving institution changes its verification standard or stops trusting the issuer.

The receiving institution should check revocation at the point required by its policy, such as before relying on the credential for onboarding or a covered transaction. The receiving institution can query an issuer-operated status service or inspect a signed status list using the credential identifier. The check should confirm the issuer, status, and update time. The institution's policy should define how to handle an unavailable or outdated status source. Responses may include delaying the decision, requesting incremental verification, or routing the case for review.

Permanent reuse creates an AML weakness because a customer may continue presenting a credential after the issuer detects impersonation, account compromise, or falsified evidence. Current sanctions and politically exposed person screening also remain necessary because those statuses can change after identity verification. Freshness and revocation checks establish whether the identity input remains usable. They do not replace transaction-specific AML controls.

Identifying gaps against institution-specific policy

A receiving institution should treat each transferred credential as an evidence bundle with defined coverage. The credential should identify which attributes were verified, which methods were used, when verification occurred, and which issuer supplied the claims. Without that metadata, the institution cannot compare prior verification with its own KYC compliance requirements.

A gap analysis maps each requirement in the receiving institution’s policy to available credential evidence. The policy may impose jurisdiction rules, risk-tier requirements, accepted sanctions lists, or product-specific transaction thresholds. Each requirement receives a status such as satisfied, stale, unsupported, or missing. The resulting report names the additional evidence or screening needed.

For example, a credential may confirm a customer’s legal name and residential address. A payment provider may still require a sanctions screen completed within the past 24 hours. The provider may also require enhanced identity evidence before granting access to a higher-risk product. The gap report preserves the accepted identity claims while identifying the checks that remain outstanding.

Inherence (opens in a new tab) provides the policy-enforcement and evidence layer for this evaluation. Inherence compiles an institution’s formalized policy rules and evaluates reused identity inputs against them before a covered action executes. Identity credentials and screening results continue to come from existing verification and AML providers.

Gap analysis should produce actionable requirements rather than a universal pass or fail decision. A missing sanctions check may block execution until a screening provider returns an acceptable result. An irrelevant document difference should not force complete re-onboarding. The receiving institution’s policy determines which gaps require new checks and which prior claims remain usable.

Running incremental KYC and AML checks

The receiving institution should map each policy gap to the smallest additional check that can resolve it. Incremental identity checks fill missing or insufficiently verified attributes. For example, the institution may request updated proof of address or stronger evidence of beneficial ownership without repeating an accepted document and biometric check. A full re-verification remains necessary when the prior credential lacks sufficient assurance or reliable provenance.

Incremental AML checks apply the receiving institution’s current controls. The platform may rerun sanctions and politically exposed person screening against its chosen lists and matching thresholds. Transaction monitoring then follows the new institution’s product rules, risk tier, and view of the customer’s activity. A prior provider’s low-risk classification does not bind the receiving institution.

Existing identity and screening providers perform these checks. The receiving platform sends each required request to the appropriate provider and passes the provider's authenticated result to the policy layer. Inherence applies the institution’s formalized policy rules to the reused inputs and new results before a covered action proceeds. Inherence does not verify identity, search sanctions lists, or operate transaction monitoring.

Each provider result should carry enough context for policy evaluation, including the check type, completion time, source, and relevant status. The institution’s policy should specify whether a missing, stale, or inconclusive result blocks the covered action or triggers review. Coverage extends only to inputs evaluated through the enforced path.

Producing independently verifiable audit evidence

Independently verifiable evidence lets an auditor test a compliance claim without trusting the wallet, payment provider, or vendor portal that produced it. A conventional audit log records events reported by the system that created the log. Digital signatures can establish the log’s origin and integrity, but they do not prove that the required policy evaluation ran correctly.

Inherence can produce a policy receipt for each covered reused-KYC decision. The complete receipt contains or references a 128-byte compressed zero-knowledge proof, public inputs defining the claim, and the verification context. A third party can check the proof using the required verification key without receiving the inputs designated as private.

The receipt proves that the covered evaluation ran against the committed policy and bound inputs. For example, the proved statement could cover the credential version, the applicable policy version, and the results supplied by screening providers. Binding the receipt to the resulting payment authorization and settlement record connects the evaluation to the transaction under review.

Proof validity alone does not establish approval, freshness, record association, replay safety, or settlement. The verifier must check those acceptance conditions separately. Inherence also does not establish the truth of every external input, including identity attributes, sanctions results, or revocation data. Those inputs remain dependent on their issuers and screening sources.

Coverage applies only to decisions routed through the defined enforcement path. Actions taken outside that path carry no proof of the covered evaluation. Auditors and regulators must still assess whether the institution chose an adequate policy, accepted suitable data sources, and handled exceptions correctly.

Decision framework: when to reuse, when to re-verify

A receiving institution should decide how much prior evidence to accept and which checks to rerun based on its own policy.

• Credential age. Compare the credential’s issuance date and underlying evidence dates with the institution’s permitted validity windows. Require fresh checks when a credential exceeds those windows or when a triggering event changes the customer’s risk profile.
• Issuing institution’s verification standard. Review which attributes the issuer verified, which methods it used, and what supporting evidence remains available. Re-verify any material attribute when the issuer’s standard falls below the receiving institution’s requirements or cannot be established.
• Jurisdictional overlap. Confirm that the prior verification covers the jurisdictions relevant to the customer, product, and proposed activity. Different document rules, sanctions regimes, or customer due diligence requirements can create gaps even when the identity data remains accurate.
• Product risk tier. Apply more scrutiny when the customer seeks access to higher-risk products. A credential sufficient for a basic wallet may not support access to cross-border transfers, credit, or products with higher financial crime exposure.
• Transaction size and pattern. Compare the proposed activity with applicable thresholds and expected behavior. Large transfers, rapid movement of funds, or activity inconsistent with the available customer profile may require updated identity evidence and additional AML checks.
• Revocation status. Reject a revoked credential. When the issuer cannot provide the status signal required by policy, block reuse or route the case for review. An unexpired credential does not establish that its supporting evidence remains valid.

The institution should encode these criteria in policy and record the inputs, policy version, decision, and checks performed. Inherence can evaluate covered actions against that policy before execution and produce independently verifiable evidence of the evaluation. The institution remains responsible for its requirements and for the external inputs used in the decision.

Implementation flow for wallets and payment providers

First, the receiving platform requests consent for specific identity attributes. The consent record should identify the recipient, permitted purpose, retention period, and credential issuer. The platform then retrieves the signed credential, its verification metadata, and any supporting proofs required by policy. The receiving institution should request raw documents only when its policy or legal obligations require them.

Next, the platform verifies the issuer, credential format, signature, expiry, and subject binding. It also queries the issuer’s revocation mechanism. A confirmed revocation should stop the flow. If the status check is unavailable or inconclusive, the institution should block reuse or route the case according to its policy.

The platform then compares the credential’s verified attributes with its own jurisdiction, product, risk, and AML requirements. The resulting gap analysis identifies each missing or stale check. Existing identity and screening providers perform the required incremental checks, such as address verification, sanctions screening, or politically exposed person screening.

Before payment execution, the compliance engine evaluates the complete set of authenticated inputs against the applicable policy version. Inherence (opens in a new tab) can compile the mandate’s formalized policy rules into an inline gate that blocks transactions that fail covered requirements. A payment integration can place the gate before wallet signing, payment credential release, or payment initiation. Stateful limits require atomic reservations, exact payload binding, and idempotency controls so retries cannot create duplicate authorization.

AP2 and x402 adapters are proposed integration designs in this architecture, not claims of demonstrated production behavior. An adapter would verify each protocol’s native authorization objects before extracting authenticated claims into a normalized payment intent. The gate would evaluate the unsigned payment payload, and the applicable protocol verifier would validate the resulting authorization afterward.

For an approved payment, the platform emits a policy receipt bound to the authorization and policy version. After settlement, the platform associates the settlement identifier with that record. The receipt proves only the covered policy evaluation against committed or attested inputs. It does not prove that every external input was true, that settlement occurred, or that actions outside the enforced path complied. Auditors must verify the receipt and its public statement, accepted verification key, freshness, payment binding, and settlement association.

How Inherence fits with identity and compliance vendors

A defensible comparison separates identity collection and screening from institution-specific policy enforcement. Identity vendors can supply verified attributes, credential records, sanctions results, fraud signals, or orchestration outputs. The receiving institution still decides whether those inputs satisfy its policy for a particular customer, product, and transaction.

Sumsub, Dock, Para, Persona, Didit, Affinidi, Sardine, and Alloy may occupy different parts of the identity, credential, fraud, screening, or orchestration market. This guide does not assign capabilities to them without links to current primary documentation. Before integrating any provider, the receiving institution should verify which authenticated outputs the product supplies, how it reports freshness and status, and whether those outputs contain enough context for institution-specific policy evaluation.

Inherence (opens in a new tab) occupies a separate policy-enforcement role. It evaluates authenticated inputs against the receiving institution’s formalized rules before a covered action executes and produces evidence of that evaluation. Inherence does not verify identity, perform screening, or prove that external inputs are true.

Inherence does not replace the identity verification, credential, fraud, screening, or orchestration functions described above. It applies institution-specific requirements to their outputs, blocks covered actions that fail policy, and produces independently verifiable evidence for actions routed through the enforcement path.

Limitations of reusable KYC

Reusable KYC cannot cover credentials or actions that bypass the enforced path. A compliance engine can evaluate only the identity inputs and transactions routed through it. Transactions completed elsewhere require separate controls and evidence.

Policy enforcement cannot establish the truth of every external input. Inherence can prove that a covered evaluation applied committed policy rules to committed or attested inputs. The proof cannot establish that an issuer collected accurate information or that a screening provider returned a correct result.

Automated gap mapping also has practical limits. An institution may use qualitative judgments, unusual exceptions, or product rules that cannot be expressed as deterministic checks. Compliance staff must review those cases and document the resulting decision.

Some re-verification will always remain necessary. Expired, revoked, conflicting, or insufficient credentials require updated identity checks. A new jurisdiction, product risk tier, or transaction pattern may also require fresh AML screening. Reusable KYC reduces repeated work when prior evidence remains suitable, but the receiving institution still applies its own policy and remains responsible for its compliance decision.

FAQ

Does reusable KYC mean an institution can skip compliance checks?

No. Reusable KYC supplies previously verified identity attributes and supporting metadata. The receiving institution must still test those inputs against its own KYC compliance policy, AML controls, jurisdictional rules, and product requirements.

Who is liable if reused identity later fails a check?

Applicable law, regulatory requirements, and participant contracts determine liability. The institution making the onboarding or transaction decision remains responsible for assessing and meeting its own obligations unless the applicable legal framework provides otherwise. Contractual recourse against an issuer or data provider does not by itself transfer regulatory responsibility. The institution making the onboarding or transaction decision generally remains responsible for satisfying its own obligations. Contractual recourse against an issuer or data provider does not automatically transfer regulatory responsibility.

How is consent for identity sharing revoked?

The available revocation method depends on the consent and credential system. When the system supports withdrawal, the wallet, provider, or credential service should record it, stop future disclosures within its control, and expose updated authorization status to relying institutions. Withdrawal does not necessarily erase records that an institution must retain or invalidate processing completed while the authorization was valid. The service should record the revocation, stop future disclosures, and expose updated authorization status to relying institutions. Revocation does not erase records that an institution must retain or invalidate processing completed under valid consent.

What happens when institutions assign different risk tiers?

Each institution applies its own risk model. A transferred credential should carry verified attributes and relevant metadata rather than forcing the issuer’s risk conclusion on the recipient. The receiving institution can request additional evidence or run incremental screening when its policy assigns a higher risk tier.

How does Inherence differ from an identity verification vendor?

Inherence does not verify documents, perform biometric matching, or conduct sanctions screening. Identity and screening providers supply authenticated inputs to Inherence. Inherence applies the receiving institution’s formalized policy rules before a covered action executes and can produce independently verifiable evidence of that evaluation. The evidence covers the defined policy check, not the underlying truth of every external input.

Apply institutional policy before relying on reused KYC

The receiving institution should apply its own policy before relying on reused KYC and preserve evidence of that evaluation. Independently verifiable receipts improve audit posture because an auditor can check that a covered decision used the committed policy version without relying solely on platform logs or receiving designated private inputs.

A receipt does not prove that every external identity or screening input was true. It proves only the checks included in its defined statement and only for actions routed through the enforced path. Inherence provides this policy enforcement and evidence layer, while identity and screening vendors supply the underlying inputs.

A wallet or payment provider that accepts third-party KYC should compare the transferred evidence with its own requirements before relying on it. Prior verification informs the institution’s decision, but the institution’s policy still determines whether to approve the customer or transaction. Prior verification supplies evidence for the institution’s decision. The institution’s own policy must still determine approval.