DOCUMENTATIONv2

POST

Transfer compliance

Issue credential

/api/v2/transfer-compliance/credentials

AUTHENTICATIONBearer token · compliance:issueAUTHORITATIVE OWNERtransfer-compliance-serviceCONTRACT AUTHORITYCapability registry · plannedSTATUSPlanned · not executable

PLANNING CONTRACT · NOT CALLABLE

This page describes intended capability and integration boundaries so people and agents can prepare safely. Do not send this request or register it as an executable tool. Wait until the capability registry marks it implemented-contract, then re-fetch the deployed OpenAPI document and build the request from that machine contract.

PURPOSE + BUSINESS CONTEXT

Planned capability: issue a scoped transfer credential from an authorized trust boundary.

WHEN THIS CALL IS USEFUL

Do not call or register this operation as an executable agent tool yet. Use this page to plan the future issue credential workflow; enable it only after the status becomes implemented-contract and the exact operation appears in deployed OpenAPI.

OUTCOME · Planned · Create or advance

What changes

None today: this route is not executable. Its intended behavior is: no executable public issuer exists. A future promotion would create one minimized issuer-signed credential and immutable issuance evidence without returning claim cleartext or authorizing a transfer.

WHY IT MATTERS

Lets people and agents prepare for issue credential without falsely presenting roadmap scope as a live capability.
Gives people and agents a contract-backed way to advance issue credential.
Supports policy-compliant transfer coordination while minimizing personal data and separating compliance evidence from value movement.

ISOLATION + AUTHORITY

Owner, workspace, counterparty, VASP, credential issuer, wallet controller, transfer, reviewer, disclosure recipient, purpose, and retention boundaries remain distinct. A credential, preparation, decision, manifest, envelope, disclosure, or Explorer record neither moves value nor substitutes for wallet authorization, sanctions policy, rail admission, settlement, or finality. This planning record grants no runtime authority, and only deployed OpenAPI can define an executable public contract.

BEFORE YOU CALL

First confirm that this operation is marked implemented-contract and exists in the currently deployed OpenAPI document; until then, no production request is valid.
Its capability-registry profile is provisional integration guidance, not an executable request schema.
Authenticate at the documented boundary: bearer+scope.
Treat the proposed subject_profile_uuid (body), credential_schema_id (body), verification_uuid (body), verification_commitment (body), claim_commitments (body), jurisdiction (body), purpose (body), valid_until (body), revocation_registry_id (body), evidence_commitment (body), step_up_token (body) as planning input only; re-generate the request from deployed OpenAPI before making a call.
Use one Idempotency-Key only for retries of the same byte-equivalent logical mutation.
Resolve the transfer parties, network, policy jurisdiction, required credential and proof classes, disclosure purpose, recipient, and retention basis.

WHAT TO DO NEXT

Keep this operation disabled in clients, agents, SDKs, and workflow automation while it remains planned-contract.
Use the stated owner, lifecycle, authority boundary, and provisional issue credential profile to prepare requirements and conformance tests without sending a request.
Monitor the capability registry for implemented-contract, then re-fetch deployed OpenAPI and validate its exact security, parameters, schemas, responses, and agent metadata before enabling the integration.

AGENT GUIDANCE

Never call this planned contract, include it in an executable tool registry, or infer runtime availability from this readable page.
Its capability-registry profile is provisional integration guidance, not an executable request schema.
Use issue credential only for the purpose and lifecycle stage described by this operation; do not treat it as authority for an adjacent action.
Treat the proposed subject_profile_uuid (body), credential_schema_id (body), verification_uuid (body), verification_commitment (body), claim_commitments (body), jurisdiction (body), purpose (body), valid_until (body), revocation_registry_id (body), evidence_commitment (body), step_up_token (body) as planning input only; re-generate the request from deployed OpenAPI before making a call.
Keep counterparty registration, credential validity, wallet-control proof, transfer intent, data preparation, review decision, disclosure authorization, delivery, value movement, and settlement as separate facts.
After a timeout or conflict, read authoritative state before deciding whether an equivalent retry is safe.
When implementation lands, discard generated requests based on this planning record and rebuild them from the deployed OpenAPI operation.

MACHINE CONTRACT

This operation is a non-executable planning contract. Its capability-registry record defines the intended owner, parameters, responses, and integration boundary until an implemented Rust OpenAPI operation replaces it.

EXTENDED INTEGRATION GUIDANCE

Readable request and response reference

Examples describe the reviewed planning contract and remain non-executable until promoted into OpenAPI.

PARAMETERS

Headers, path, query, and body

NAMELOCATIONPRESENCETYPE / RULES / PURPOSE

AuthorizationheaderRequired

Bearer tokenCredential containing the compliance:issue scope.EXAMPLEBearer hc_live_…

Idempotency-KeyheaderRequired

ASCII string · 1–128Caller-generated key reused for every retry of the same logical mutation.EXAMPLElaunch-treasury-v1-001

Content-TypeheaderRequired

application/jsonSigned mutations accept canonical JSON only.EXAMPLEapplication/json

Content-DigestheaderRequired

RFC 9530 SHA-256 digestDigest of the exact transmitted body bytes.EXAMPLEsha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=:

Signature-InputheaderRequired

RFC 9421 signature parametersCovers @method, @path, content-digest, content-type, and idempotency-key; includes keyid, nonce, created, and expires.EXAMPLEsig1=("@method" "@path" "content-digest" "content-type" "idempotency-key");created=1786582800;expires=1786583100;nonce="01J…";keyid="machine-prod"

SignatureheaderRequired

Ed25519 HTTP Message SignatureSignature made by an active public key registered to the authenticated client.EXAMPLEsig1=:base64-signature:

subject_profile_uuidbodyRequired

32-character tenant-visible subject identifierExact subject selected by an independently authorized issuer.EXAMPLEf8317aef81764e1f923037c1b76df8de

credential_schema_idbodyRequired

versioned allowlisted schema identifier · max 96Exact issuer-owned claim schema and semantic version.EXAMPLEhybrid-transfer-person-v1

verification_uuidbodyRequired

32-character identifierCompleted subject verification that supplies the issuance evidence boundary.EXAMPLEc61d80befec6449ab7260c5cd11d42f8

verification_commitmentbodyRequired

64-character SHA-256 digestCommitment to the exact completed verification version and minimized issuance evidence.EXAMPLEcccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

claim_commitmentsbodyRequired

claim-key → SHA-256 digest map · 1–64 entriesSmallest schema-allowed claim set. Claim cleartext, documents, biometrics, and screening matches are forbidden.EXAMPLE{"legal_name":"dddd…","country_of_residence":"eeee…"}

jurisdictionbodyRequired

jurisdiction code · max 16Issuer jurisdiction and policy context retained with the credential.EXAMPLECH

purposebodyRequired

identifier · 3–96Purpose limitation applied to later disclosure and relying-party evaluation.EXAMPLEREGULATED_TRANSFER

valid_untilbodyRequired

RFC 3339 timestampCredential expiry bounded by policy and underlying evidence freshness.EXAMPLE2027-09-01T00:00:00Z

revocation_registry_idbodyRequired

issuer-controlled registry identifier · max 96Registry in which lifecycle revocation can be published without disclosing claims.EXAMPLEtransfer-credentials-2026

evidence_commitmentbodyRequired

64-character SHA-256 digestCommitment to retained issuer review and approval evidence.EXAMPLEffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

step_up_tokenbodyRequired

one-use purpose-bound tokenFresh TRANSFER_CREDENTIAL_ISSUANCE authorization bound to issuer, subject, schema, and evidence.EXAMPLEhcsu_…

REQUEST

JSON body example

{
  "subject_profile_uuid": "f8317aef81764e1f923037c1b76df8de",
  "credential_schema_id": "hybrid-transfer-person-v1",
  "verification_uuid": "c61d80befec6449ab7260c5cd11d42f8",
  "verification_commitment": "cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc",
  "claim_commitments": {
    "legal_name": "dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd",
    "country_of_residence": "eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee"
  },
  "jurisdiction": "CH",
  "purpose": "REGULATED_TRANSFER",
  "valid_until": "2027-09-01T00:00:00Z",
  "revocation_registry_id": "transfer-credentials-2026",
  "evidence_commitment": "ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
  "step_up_token": "hcsu_…"
}

RESPONSES

Status and payload examples

501Profiled planning contract only; no separately authenticated public V2 credential issuer exists and the operation is absent from live OpenAPI.Not executable · JSON RESPONSE+

{
  "code": "planned_contract",
  "message": "Formal transfer credential issuance is not available through V2."
}

INTEGRATION DECISIONplanned_contract

CALLER ACTION: Do not send this request or register it as an executable agent tool. Use the implemented alternatives linked by the module guide.
RETRY SAFETY: Do not retry on a timer. Re-fetch production OpenAPI and proceed only after this exact operation appears there.
STATE RECONCILIATION: No runtime state exists to reconcile for this planning contract. Continue from transfer-policy definitions, credentials, attestations, reviews, commitments, decisions, and revocations through an implemented operation.
ESCALATE WHEN: Escalate when minimized compliance evidence, issuer authority, policy version, jurisdiction, or decision lineage cannot be verified.

OPERATIONAL NOTES

Security and lifecycle guarantees

Do not call this planning route. compliance:issue is deliberately separate from subject compliance:write and reviewer compliance:review authority.
Never submit claim cleartext, identity documents, biometric media, screening matches, wallet secrets, private signing keys, or raw verification evidence. A future issuer signs commitments and minimized metadata only.
A promoted 201 would mean formal credential issuance, not subject consent for a counterparty, selective disclosure, transfer approval, broadcast, settlement, or value movement. Relying parties must still verify issuer key, signature, schema, purpose, status, validity, revocation, evidence freshness, and their own policy.
Promotion requires a named authoritative tenant issuer, protected signing keys, allowlisted schemas, verification-version and consent binding, claim minimization, revocation and suspension lifecycle, expiry, evidence audit, and conformance tests.

DOCUMENTATION STATUS

This planned contract now defines its public parameters, authorization boundary, replay behavior, responses, and authoritative owner. It remains non-executable until its owner adapter and conformance tests are promoted into the Rust gateway.

Return to the V2 directory ↗