Registration & KYC — The Design

No verdict, no reasons stored. "Usable vs pending" is local (record absent vs present). "Why pending / which step" is core's, fetched on demand for the consumer signal. Fund-once is one conditional update:

-- claims the record so two nudges can't double-fund
UPDATE payment_card
  SET pending_activation = NULL, funded_ref = :ref
WHERE id = :id AND pending_activation IS NOT NULL
RETURNING deferred_amount, deferred_channel;

Row + amount returned ⇒ load it at the processor using :ref (idempotent there too). No row ⇒ already cleared ⇒ no-op. A record with no amount ⇒ just unsuspend.

• core = compliance brain. Defines what verification is required, resolves the amount-banded KYC level, runs providers, and holds the authoritative record + history (kyc_result + Envers). Verification attaches to the person.
• axis = card & funds engine + sole processor gateway. Owns card state, the pending-activation record, and all Tribe ops. Reads the design requirement locally (the static booleans, keyed by (program, design) — fixing today's designId-only lookup); asks core for the verdict.
• The calls already exist both ways. core→axis (release); and axis→core (CoreApi/Persons via core.api.baseUrl, already used in CardAccountMultiActionValidator). The verdict check reuses this established direction — not a new dependency.
• Two authorization surfaces. Partner-facing (/api/cpm/*, partner role + program scope) for activate/load; orchestrator/internal (the /internal-api/* pattern, a role only core holds) for release / hold / replace.
• The consumer signal is a live contract. requiresKyc / kycLocked flow platform-core → axis API → setldhub-api (.NET) → setldhub → card-balance-ui. The DTO keeps emitting them derived — kycLocked = pending-activation record exists, requiresKyc = design needs kyc — so consumers keep working unchanged; renaming is a coordinated multi-repo migration.

• The new card takes over; the source is retired.
• Usable source → balance moves to the replacement, usable. The holder is already verified (verification is on the person), so no re-verification.
• Pending source → the pending-activation record carries over to the replacement (deferred amount and all); it releases on verification, gated by the same core check. Done within axis (single owner, one atomic claim) — no cross-service clone, no race.

The card-status enum is a processor mirror in a shared library, consumed by exhaustive switches that throw on unknown values — and the processor has no "pending verification" code. A new status would mean a shared-library change, a fake mapping, and risk to every switch — and it would be wrong: "suspended at the processor" and "awaiting verification" are different concerns. So a pending card sits at the processor's normal suspended code, and the pending-activation record carries the verification meaning. usable = active and no record.

The heavy core-side machinery turns out to be unreleased — only on the feat/246-card-expiry branch, absent from prod. The genuinely fixed surface is narrow.

"On main" ≠ "in prod" — all six repos deploy manually, so the prod schema is the only definitive released signal. initial_funded_date has no fee/expiry reader anywhere — axis, core, .NET, and the Node platform services all checked, none found — and is the same "claimed/funded" marker as the pending-activation record, so fold it in, don't preserve it. The V6 migration is deployed to staging (feat/246 integration) but absent from dev and prod. Branch-verified: the card-expiry feature anchors expiry on the activation date (CardUpdateActivity.createdTs) — explicitly even for held cards — not on initial_funded_date.