XKOVA Docs
Integrations and Orchestration
Beyond the two product pillars, XKOVA is an orchestration layer. It owns the policy, ledger, audit trail, member identity, and settlement state, and it connects to the rest of an institution's stack through swappable adapters. You plug in the vendors you already trust, and you are never locked into one stack.
Why orchestration matters
Closed competitors bundle wallets, blockchain networks, compliance, stablecoins, and ramps from a single provider. Switching any one piece means rebuilding. XKOVA takes the opposite stance: each connection is an adapter behind a stable interface, so a vendor can be swapped without touching the product surface above it.
The connections
Each category lists the vendor live today and examples of the interchangeable vendors the adapter seam is designed for. An institution chooses one per category; a category with no live vendor named runs on the included sandbox provider until one is configured.
| Connection | Vendors | Where it surfaces |
|---|---|---|
| Core Banking | The institution's own core (Symitar, Corelation, Fiserv, and similar) behind its integration gateway | Integration gateway |
| Screening (KYT and BSA) | Chainalysis (live); TRM Labs, Elliptic (pluggable) | Compliance pipeline |
| Identity (KYC and KYB) | Persona, Alloy, Onfido (pluggable; a sandbox provider ships today) | Verification flows |
| Conversion and Ramps | Coinbase, Paxos, Anchorage (pluggable; a sandbox provider ships today) | Funding and off-ramp |
| Wallet Providers | Thirdweb (live); Turnkey, Fireblocks, Privy, Crossmint (pluggable) | Configured per tenant |
| Blockchain Networks | Avalanche, Base, any EVM | See Supported Networks |
| Treasury Custody | Safe (Gnosis) (live); Fireblocks, Anchorage (pluggable) | See Treasury |
The adapter model
Each category sits behind a provider interface. In the sandbox, every interface runs against a simulated implementation, and in production the same interface points at a real vendor. The product code above the interface does not change when the vendor does. This is what keeps the platform open.
Managing an Integration Gateway
The Integration Gateway that connects XKOVA to an institution's core is deployed and wired to the core
during onboarding, as described in Core Banking. Once a gateway is deployed,
an admin in your tenant manages its registration, security posture, health, and call history through the
management API under /v1/integration-gateways. These operations manage the deployed gateway's
record with the platform; they do not point XKOVA at a new core on their own, and they are workspace scoped,
so a tenant only ever sees and manages its own gateways.
| Operation | Method and path | What it does |
|---|---|---|
| List | GET /v1/integration-gateways | List the gateways the tenant has registered, each with its status, pinned certificate fingerprint, and latest conformance result. |
| Register | POST /v1/integration-gateways | Register a deployed gateway
with a name and a base_url. The new gateway starts in the
registered status. |
| Get | GET /v1/integration-gateways/{id} | Read one gateway's full record. |
| Edit registration | PATCH /v1/integration-gateways/{id} | Update the
name or base_url. Only the fields you send are written. |
| Pin or rotate cert | POST /v1/integration-gateways/{id}/pin-cert | Pin the
gateway's mTLS certificate fingerprint for the mutually authenticated channel. |
| Enable or disable | POST /v1/integration-gateways/{id}/status | Set the
status to active, disabled, or registered. |
| Record conformance | POST /v1/integration-gateways/{id}/conformance | Record
a contract conformance result of passing, failing, or unknown. |
| Read events | GET /v1/integration-gateways/{id}/events | Read the log of calls XKOVA made to the gateway, newest first. |
Gateway management is admin only. It is tenant configuration rather than an access grant, so the operations
are held by the admin permission set (gateway.read for the reads,
gateway.register, gateway.repoint, gateway.pin_cert,
gateway.activate, and gateway.conformance for the writes) and are not part of any
lesser operator role. Every mutation is recorded in the audit trail as a configuration change. The write
operations accept an idempotency key so a retried call is safe; see Idempotency.
Lifecycle and status
A gateway carries a status of registered, active, or
disabled. Registration creates the record in registered; enabling moves it to
active so the platform routes core banking calls to it; disabling stops the platform routing to
it without removing the registration, so it can be re-enabled later. In a tenant that gates gateway activation
behind a governance approval, an enable request is held for a quorum: the gateway is unchanged and the response
carries a pending_approval_request_id, and you re-issue the enable once the approval clears.
Certificate pinning and rotation
The mTLS channel to the gateway is pinned to a certificate fingerprint. Pinning is done with a public sha256
digest, never key material. Pinning a new fingerprint rotates the current one into
previous_cert_fingerprint and stamps cert_rotated_at, so a rotation keeps a record of
the fingerprint it replaced. The pinned and previous fingerprints are readable on the gateway record.
Conformance
A conformance result attests that the deployed gateway matches the expected adapter contract, the same
contract the operations in Core Banking describe (resolve member, check funds
available, place hold, release hold, capture hold, credit member, list operations, and notify member). Recording
a result sets conformance_status to passing, failing, or
unknown and stamps conformance_checked_at, so the gateway record carries its most
recent conformance state.
The event stream
Every call XKOVA makes to a gateway is logged, and you read that log through the events endpoint, newest
first with cursor pagination (pass a prior response's next_cursor; limit defaults to
25 and caps at 100). Each event records the operation (op), the HTTP method, whether
the call succeeded (ok), the upstream_status and error_code on failure,
the latency_ms, and the idempotency_key if one was sent. This is distinct from the
gateway's own operation stream in Core Banking, which an integrator reads for
core ledger reconciliation: the event stream here is XKOVA's outbound call log for observing gateway health.
Where to go next
Read each connection page for the vendors it supports and how it is configured: Core Banking, Screening, Identity Verification, Conversion and Ramps, and Wallet Providers.