$ENGINE for the engine’s URL and $TOKEN for your connector’s bearer.
Your own KYC
Onboard an investor whose KYC ran outside NodeAsset in one call: it registers the holder, binds it to the KYC case by the provider and the provider’s own reference (no personal data), and records the attributes that case established. The call is idempotent on the provider, the reference and the party, and takes four eyes: your connector makes it, an approver approves it.curl
onboard-conflict, its check naming the binding. Then offer the admission, as in Onboard investors.
A provider’s credential
For an asset that requires its register keeper’s credential, the claims are read on the ledger off credentials your KYC provider issues the investor, and the attributes are not used. The provider issues each investor a DA credential carrying its claims as codes (residency, investorType, accreditation), with the end of its evidence as the credential’s validUntil or a <topic>ValidUntil claim, and names the venue’s party among its observers so the venue can present it. The provider is one the register keeper trusts: the asset’s policy names it in admission.trustedIssuers, and the register keeper accepted those terms into its admission consent. Then admit the investor, as in Onboard investors: the register keeper’s own credential is created, and the investor accepts nothing.
Provider webhooks
Your connector receives the provider’s verification webhook, checks it the way the provider says, and turns each result into the same calls:
Each claim carries its expiry (
residencyValidUntil, and so on), so the venue’s credential lapses on its own when the KYC does: an investor whose credential lapsed can neither receive, send nor redeem until it renews. Recording attributes takes four eyes, so a person approves what the connector made.
Under the register keeper’s credential, the provider’s own credential is the result: a new or renewed result is a credential the provider issues, and the next admission re-issues the register keeper’s with its claims. The register keeper’s credential names no end. The venue reads the claims afresh at each of its acts, so a lapsed or revoked result counts at once there, and the register keeper revokes its credential to stop the investor on the registry.
Screening
A hit freezes the investor
Acting on a screening hit takes one call, by a bearer with thecompliance role (or risk), and the freeze takes effect at once: every order, redemption, admission and distribution of the investor is refused holder-frozen, with the freeze’s reason. For a freeze on every asset, the register keeper’s block list follows (its own systems read GET /v1/block-list, under the registrar role), so even a transfer between custodians that never reaches NodeAsset stops. Each freeze is announced holder.restricted.
curl
mode:freezestops everything;liquidate-onlylets the investor redeem and leave, as for a lapsed KYC ("reason": "kyc-lapsed").reasoncomes from a closed list:sanctions,court-order,regulator-order,kyc-lapsed,credential-lapsed,investigation,deceased,key-loss,other. A court or regulator order is cited, with the document’s SHA-256 (order).instrumentIdlimits the restriction to one asset, andautoReleaseAtends it at a set time.POST /v1/restrictions:batch-createrestricts many holders on one asset, all or none.
screening: its state (clear, potential-match, confirmed-match), when, the provider and its case reference. It is kept with each version of the attributes and supports no claim: a hit is acted on by a restriction, as above. holder.restricted names the restriction’s reason code.
Two approvers lift it
A lift names the one restriction it lifts, so lifting a lapsed-KYC limit never lifts a sanctions freeze. The maker’s call comes back pending until two other approvers, neither of them an auditor, sign it; the lift is then announcedholder.unrestricted.
curl