Sandbox APIhttps://sandbox-api.nuvante.io

Explainers

Agentic compliance

How we keep automated compliance checks accountable, and how software can initiate transactions on a participant's behalf.

The problem it solves

Compliance work covers sanctions screening, transaction monitoring, Travel Rule data and reviewing suspicious activity. All of it involves judgement calls on information that changes quickly. At clearing-platform volumes, that means using automated agents to do the analysis.

Doing it accountably means being able to show, after the fact, exactly what an agent saw, what it decided and why. Regulators and auditors won't accept "the algorithm flagged it" as an explanation.

How compliance agents are structured

Each compliance agent does one narrow job and passes its output to the next step. There are separate agents for KYB and KYC, wallet screening, transaction monitoring and the Travel Rule. None of them makes a final call alone. When the transaction-monitoring agent scores an alert, that alert goes into a queue for a human reviewer.

  • An explicit rejection triggers a safe, automatic unwind. This follows the same rule as an issuer REJECTED status in Instruction lifecycle.
  • An ambiguous or high-risk signal never resolves automatically. It parks and waits for a person, just like an issuer FAILED status.

Every step an agent takes is logged in an auditable execution history. The log records the full sequence of checks that led to a decision, along with the decision itself.

Agent-initiated transactions (sandbox)

Separately from our internal compliance agents, software can also start transactions on behalf of a clearing participant. Status: Live.

A tenant admin creates (mints) a sandbox agent with a mandate. The mandate is checked against the admin's own capabilities, so an agent can never be given more than its principal already has. If a mandate has expired or been revoked, the transaction is rejected before it reaches the clearing core. Minting, listing, revoking, and initiating with the optional agent field are all covered in Agent-initiated transactions.

Cross-platform interoperability

Longer term, we expect counterparty agents to initiate transactions across organisations. These would be pieces of software acting for a clearing participant, possibly using protocols like AP2 or x402. The guiding principle is capability intersection. An agent shows its identity and proves the request sits inside the overlap between what its principal can already do and what its credential allows.

Exchanging mandates across platforms and agreeing production authorisation protocols are still open design questions. Status: Design Today's sandbox applies the intersection rule within a single participant.

For administrators

Administrators can inspect the compliance agent history behind any flagged transaction. The Administrator guide explains which parts you can reach through the API and which need the console.