Registration & KYC — The Seams

Correction. An earlier pass stopped at "pure pass-through, empty blast radius." That holds for the .NET middle tier only — and it was the wrong place to stop. The fields cross setldhub-api / card-balance-api / IncommListenerApi unbranched, then are actively branched on in two Angular front-ends. A semantic change is observable; the contract is the field names and their truth-conditions.

Both UIs read requiresKyc && kycLocked as "pending verification" — which matches the design's intended meaning, so derive-and-keep-emit still works as long as the truth-conditions hold: kycLocked ⇔ held-pending, requiresKyc ⇔ needs registration, deferredLoadAmount ⇔ the parked amount.

Constants.CardStatus (platform-core) is a processor mirror: Activated, Blocked, Suspended, Risk, Stolen, Lost, Expired, NotActivated, Fraud. There is no "pending verification" value — confirmed absent. Constants.KycStatus is just {Verified, Unverified}.

• Adding an enum value is serialization-safe but the brittle part is axis-side: CardStatusMapper.fromTribeStatus*() switches over raw Tribe codes (A/B/T/R/S/L/E/N/F) and throws on unknown. flexible (axis)
• The design's choice holds: keep verification off the status enum (it's a separate concern, modelled as the pending-activation record). A pending card sits at the processor's normal Suspended code; the record carries the verification meaning.

No deleted_at on this table. Tribe status ("A"/"T") lives at the processor, mirrored via card_update_activity. Bucket: columns released; meaning is flexible (the design replaces the boolean with record-presence, keeping the column emitting kycLocked for compat or retiring it via migration). Shared read: core also maps cpm.payment_card (its own PaymentCardEntity → REQUIRES_KYC) and re-derives its own requiresKyc — so like cpm.kyc_lock, it's read by both Java services.

Created by core Flyway V12 (on main). axis maps it read-only via ProgramConfigurationEntity (@Table(name="program_configuration", schema="core")) — a cross-service read over a shared table, not an API. The lock requirement is read from here.

Two seam facts: (1) retiring the dead fund flags (design OPEN-5) is a core migration, coordinated, not an axis change. (2) The lookup ProgramConfigurationRepository.getByDesignId returns list.get(0) with no deleted_at filter though the column is mapped — defect D6, a one-line axis fix. The design also re-keys this read on (program, design), not designId alone.

The 4-flag space is mostly theoretical. Active (deleted_at IS NULL) configs in prod collapse to two shapes:

In prod, locked ⟺ fund_postreg ⟺ (kyc ∧ reg) — the dead flag happens to agree 100%, and reg/kyc are always both-set or both-clear. fund_init is false everywhere ("lock + pre-fund" has zero instances). The reg-only Touchwood shape is not in prod (staging-only) — so the redesign has room to define its behavior before it ships.

The "is this person verified, to what level" read — already wired, already used. This is the channel for the design's amount-aware, never-cached verdict check.

// axis Persons.getPerson → CoreApi
GET /core/api/v1/{partnerExternalId}/person/{uuid}
// → core PersonController.getPerson :135 → GetPersonResponse
kycResults: List<KycResultDTO> { status:KycStatus, kycLevel:KycLevelEnum, validFrom, validUntil }

axis reads kycResults and compares level to the amount band — the "verdict" the design checks at money-movement. (A write-side POST …/person/{uuid}/card/{cardId} = validateOrLinkCard also exists.) Bucket: the call exists and is flexible to consume more deeply; no new dependency direction.