Registration & KYC -- Conformance Spec

• To validate a fix: walk it against every SETTLED requirement's accept-criteria. For each OPEN requirement, confirm the fix implements the branch the decision picked.
• Each requirement (REQ-xx) is a behavioural rule + Given/When/Then accept-criteria + references + a status.
• The master decision table (section 3) is the coverage backbone — the exhaustive (design x action x amount) → outcome grid the requirements cite.
• Consumer contracts (section 2) (C-xx) are the obligations of each surface that shows or acts on the state.
• The coverage map (section 6) ties every known defect to the requirement that catches it — so this list is a regression guard for the real bugs, not an aspiration.
• Altitude: requirements describe behaviour, not encoding. "Show the card as held and offer registration" is the requirement; which field carries it is a design choice.

Four concerns, kept separate. Each can be reasoned about and reported on its own.

Usability is one binary axis — held vs usable (an open card is simply never held) — but "held" decomposes into verification sub-states.

Verification sub-states — "Pending" is not one state

A held card sits in exactly one of these. axis enforces only the binary (held vs usable); the sub-state — the reason — is the verdict authority's (core's), surfaced to consumers. None of these are processor card-statuses.

What each surface that shows or acts on the verification state MUST do. Behavioural — encoding is the design's choice.

C-STATE

The platform makes a card's verification state distinguishable — the held/usable fact on the card, the precise reason from the verdict authority on demand.

• From the card a consumer can tell: open vs held vs usable; that it needs registration and/or KYC; and the deferred amount if any.
• The precise sub-state — awaiting-registration vs registration-failed vs awaiting-KYC vs KYC-failed — is the verdict authority's (core's), obtainable on demand.
• No two fields or endpoints may report conflicting answers to "does this need verification."

C-FUNNEL

The cardholder site holds back a verification-required card and offers the path to complete it.

• Given a card whose design needs registration and/or KYC, not yet verified When the holder views it Then it is shown as held and the holder is offered the registration / verification path.
• This fires for registration-only designs as well as KYC designs.
• When the card is verified Then it behaves like an ordinary usable card.

C-ADMIN

SetldHub shows that a card is held and why, and never presents not-yet-loaded funds as spendable.

• A pending card shows as held with the reason — awaiting registration, awaiting KYC, or both.
• Deferred (not-yet-loaded) funds are never shown as a spendable/available balance.

C-VERDICT

The compliance authority is the single source of "is verification satisfied," answered live at money-movement.

• Funds move only on a current "verified for this holder and this amount" — never a cached verdict.
• The verdict is amount-aware: a load needing a deeper level than the holder holds does not pass.
• If the verdict is unavailable (authority down or times out), the operation fails closed — no release, no money.

The exhaustive backbone. Every requirement cites these rows.

Behavioural rules with pass/fail criteria. SETTLED = testable now. OPEN-n = pending a decision. SECURITY = must-fix invariant.

A -- Activation

B -- Loading & Funding

C -- Release / Verification

D -- Replacement / Transfer

E -- Consumer Signal & Display

F -- Group Activation

G -- Safe Migration

Each carries both candidate outcomes so it becomes a hard test the moment it's decided.

Every known bug mapped to the requirement that catches it. If a requirement here is met, the listed defect cannot recur.

Stated as invariants (what must hold), not mechanism (how). The design picks the how.

• Auditable. Every state transition and every release attempt — allowed and denied — is recorded with the caller's identity.
• Defined, non-leaking error outcomes. Every reject has a defined outcome that leaks no internals.
• Funded-once is keyed. The fund-once guarantee rests on an idempotency key — keyed per deferred-record, honoured for the record's life, and surviving a card-id change across replacement.
• Single-currency. A deferred load, an extend, and a replacement are single-currency — a currency mismatch is rejected, not silently converted.
• Detectable. A card entering a failed / stranded sub-state, an unfunded-at-release, or a spike in denied releases raises an alert.
• Security beyond REQ-C4. Authorise the inquiry / screening branch too (PII); scope the verdict read; treat the person id in a release as authorisation-relevant; the release nudge tolerates replay and is rate-limited.
• Existing state & data are migrated. The fix must remediate the already-stranded prod cards and migrate the existing parked-load rows into the new record shape.