Who's Building Compliance Infrastructure for Autonomous Finance and AI Agent Payments: A Startup Landscape

TL;DR

• AI compliance for autonomous finance concerns crypto-native transaction controls, unlike the enterprise model governance offered by Fiddler, Zenity, and OneTrust.

• The trust stack comprises identity, authorization, runtime enforcement, compliance and audit, and settlement.

• t54 Labs covers identity and authorization through agent credentials, confidence scores, and credit underwriting.

• Newton Protocol uses decentralized attestations for runtime enforcement. Nava pairs pre-execution checks with an audit trail. Predicate embeds policy checks and decentralized validation into protocols.

• Inherence spans runtime enforcement and compliance through pre-execution policy checks and privacy-preserving zero-knowledge receipts. Settlement remains a separate infrastructure layer.

Why enterprise AI-governance tools are the wrong reference class

Enterprise AI-governance platforms address model and application oversight. Fiddler, Zenity, and OneTrust help organizations monitor AI behavior, manage risk, document controls, or investigate activity. Their records can support governance reviews, but those records do not inherently stop a wallet or smart contract from transferring assets.

Autonomous finance requires controls inside the transaction path. A pre-execution compliance engine evaluates a proposed payment or trade against identity, authorization, risk, and policy conditions before crypto-native rails settle it. The engine permits an approved action or blocks a violation while the assets remain under control.

A company belongs in this category when its product contributes directly to that pre-settlement decision. Identity scores and attestations may provide inputs, while policy engines and protocol checks may enforce the final decision. Each mechanism governs whether a financial action proceeds rather than whether a model produced an acceptable response.

An audit trail also serves a narrower purpose here. It records the authorization or policy evidence attached to each transaction, ideally in a form that another party can verify. Conventional AI compliance logs usually describe prompts, outputs, access, or model behavior after an event. Those logs may support investigations, but they do not prove that financial rules governed the transaction before settlement.

The five-layer trust stack for autonomous finance

The five-layer trust stack separates the functions required to approve, control, verify, and complete an autonomous financial transaction. Each layer answers a different question about the agent, its authority, its conduct, or the resulting transfer.

• Identity establishes which person, organization, wallet, or software agent initiated an action and attaches relevant credentials or risk signals.

• Authorization determines which actions that identified actor may take under permissions such as spending limits, approved counterparties, and delegated mandates.

• Runtime enforcement evaluates each proposed transaction against applicable rules before execution and blocks actions that fail those checks.

• Compliance and audit records evidence of the decision so a counterparty, auditor, regulator, or protocol can review the transaction and its governing policy.

• Settlement transfers value through a payment network, blockchain, exchange, or other financial rail and records the transaction as complete.

A compliance engine may connect several layers without replacing them. For example, a runtime control can consume an identity credential and a sanctions-screening result, check both against an authorization policy, and then submit an approved transaction for settlement. The engine can also produce an audit trail through logs, attestations, monitoring records, or cryptographic receipts.

The five layers describe functions rather than mutually exclusive vendor categories. t54 Labs operates mainly across identity and authorization through confidence scores. Newton Protocol focuses on runtime enforcement through decentralized attestations. Nava combines runtime checks with an audit trail, while Predicate connects authorization policies to protocol-embedded enforcement. Inherence spans runtime enforcement and compliance and audit by blocking policy violations before execution and producing a zero-knowledge receipt for approved actions.

Most entrants therefore appear in more than one layer. Their placement depends on where they make a decision, what evidence they produce, and which parties a verifier must trust. Settlement rails and upstream identity providers remain separate parts of the stack even when an enforcement product integrates them.

t54 Labs: confidence-score trust for agent identity and credit

t54 Labs concentrates on the identity and authorization layers through agent identity scoring and risk-based underwriting. Trustline screens agents and transactions for institutional finance, while its Know Your Agent model evaluates identity, reputation, and risk signals. ClawCredit uses those signals to underwrite credit lines for autonomous agents.

Company figures report more than 20 million transactions screened, over 41,000 agents verified, and decision latency below five seconds. t54 Labs has raised $5 million, and Ripple backs the company. Founder Chandler Fang previously worked at Ripple.

The t54 Labs mechanism produces a probabilistic confidence score based on multiple inputs and approvals. A decision might report that seven of eight checks approved an agent with 87.3 percent confidence. A counterparty can use that score to approve a payment, price credit, or require further review.

A confidence score estimates whether an agent or transaction presents acceptable risk. The score does not cryptographically prove that a specific transaction satisfied a specific policy. t54 Labs has not disclosed a zero-knowledge receipt or comparable artifact that an independent party can verify without relying on its risk model. Its privacy approach focuses on protecting credentials during credit underwriting rather than concealing transaction details through zero-knowledge proofs.

Newton Protocol: decentralized attestation at the smart-contract layer

Newton Protocol places transaction authorization at the smart-contract layer, where policies can approve or reject an onchain action before execution. Developers encode spend limits, sanctions checks, fraud controls, and other AI compliance rules through its SDK. The compliance engine operates as an Actively Validated Service on EigenLayer, with a decentralized operator network evaluating each request.

Each Newton decision carries a BLS attestation from the operator network. BLS signatures let multiple operators combine their approvals into a compact signature that a smart contract can verify. A verifier therefore trusts that Newton’s operators evaluated the relevant policy correctly and reached the required consensus. The signature authenticates the network’s verdict, but it does not independently prove the underlying compliance condition.

Newton uses a chain-agnostic integration model across EVM networks and currently supports Ethereum, Base, and Arbitrum. The same model can serve wallets, decentralized applications, AI agents, and DeFi protocols. Newton records hashes or commitments onchain rather than personally identifiable information, which limits public data exposure. Its privacy model still reveals enough information for the operator network to evaluate the policy, unlike a zero-knowledge proof that can conceal the underlying policy or transaction details from the verifier.

Nava: architectural separation and audit trail

Nava uses architectural separation to enforce policy before an agent moves funds. Its Guardian operates as an independent engine that reviews each proposed action, applies policy checks, and returns an approve or reject verdict before execution. Nava describes the sequence as Propose, Verify, Execute.

Guardian also returns a reason code, safety flags, and an audit trail. The verdict belongs in the runtime-enforcement layer because it can block an action before settlement. The recorded decision and supporting information place Nava in the compliance and audit layer, where operators can review what the engine checked and why it reached its verdict.

Nava’s model depends on counterparties trusting Guardian to apply its policies and report the decision accurately. The available materials do not describe a cryptographic proof that lets an outside party verify compliance independently, nor do they claim privacy-preserving verification. Nava instead exposes the verdict and related reasoning through its audit trail.

Current venue coverage includes Uniswap and Hyperliquid, and most broader product access remained gated or pre-launch at the time of research. Nava therefore provides a clear model for separated pre-execution review, but its demonstrated scope remains limited to those venues.

Predicate: protocol-embedded enforcement with decentralized data partners

Predicate operates across the authorization and runtime-enforcement layers by placing policy checks inside the transaction path. Protocols can embed a Predicate function in smart contracts or infrastructure such as bridges and nodes. The function evaluates programmable conditions and returns true or false before the onchain action proceeds.

Predicate’s Information Provider marketplace supplies the external data used for real-time decisions. TRM Labs, Elliptic, and Crystal provide transaction-risk and anti-money-laundering data. Human.tech contributes identity verification, while Webacy supplies trust and safety signals. Witness Chain supports geolocation checks. Protocols can update policies as requirements or provider data change.

The embedded model suits protocols and asset issuers that want composable rules at the application or asset level. Example uses include blocking sanctioned addresses, enforcing clean-asset requirements in DeFi pools, and placing transaction limits on AI agents or wallets. Predicate also provides transaction monitoring, policy testing, and downloadable histories for the audit trail.

A verifier relies on Predicate’s protocol infrastructure, its decentralized validation model, and the accuracy of the selected Information Providers. Public materials do not describe the core decision as producing a portable zero-knowledge receipt that a counterparty can verify without those dependencies. Predicate therefore differs from confidence-score systems and self-contained proof systems in how it establishes trust, even when each approach blocks a transaction before settlement.

Inherence: pre-execution enforcement gate with zero-knowledge receipts

Inherence operates in the runtime-enforcement and compliance/audit layers. Its compliance engine converts a written policy into an inline gate that evaluates each proposed financial action. The gate blocks actions that violate the policy before execution and issues a zero-knowledge receipt for actions that pass.

For a reference policy containing 112 constraints, gate latency measured 27 to 250 nanoseconds for policy evaluation. The supplied benchmark record does not specify the processor used for that latency test. Proving time measured approximately 2.6 milliseconds on an Apple M4 using 10 threads. Each Groth16 receipt measured 128 bytes.

A verifier checks the receipt cryptographically without accessing private transaction inputs, relying on a vendor dashboard, or trusting the operator’s audit trail. The receipt confirms that the covered action satisfied the encoded policy while keeping details such as amounts, exposure thresholds, and strategy rules private. An attestation instead requires the verifier to trust the designated signer or validator network. A confidence score depends on the scoring model and its underlying data, while dashboard monitoring depends on the operator’s records and access controls.

Inherence does not replace identity checks, sanctions screening, or transaction-risk providers. Those systems supply facts or verdicts that policies can use. Inherence binds the applicable policy to execution and produces per-action evidence for AI compliance review.

Comparison: enforcement model, verification method, and privacy approach

The verification method determines what a counterparty must trust and what transaction data the counterparty can inspect.

Company	Layer(s)	Enforcement model	Verification method	Privacy approach	Best for
t54 Labs	Identity, authorization	Agent identity and risk scoring	Confidence score	Private credentials for underwriting	Agent reputation, screening, and credit
Newton Protocol	Authorization, runtime enforcement	Smart-contract policies enforced by an operator network	Decentralized attestation	Hashes and commitments keep personal data offchain	EVM applications needing decentralized authorization
Nava	Runtime enforcement, compliance/audit	Independent Guardian approves or rejects proposed actions	Dashboard and monitoring audit trail	No disclosed ZK transaction privacy	Agent builders wanting separated pre-execution checks
Predicate	Authorization, runtime enforcement, compliance/audit	Boolean policy checks embedded in contracts, bridges, or nodes	Decentralized validation using external data providers	Privacy depends on integrations and data providers	Protocols and issuers needing embedded onchain policy
Inherence	Runtime enforcement, compliance/audit	Policy gate blocks violations before execution and issues a receipt	ZK proof	Verifiers see policy compliance without private inputs	Transactions needing portable, independently verifiable evidence

Where settlement and identity layers still depend on incumbents

Sardine, ComplyAdvantage, and Bretton support identity, screening, and compliance decisions that runtime enforcement products can consume. Chainalysis and TRM Labs provide blockchain analytics, address attribution, and transaction-risk signals. These vendors supply upstream data rather than compete directly with t54 Labs, Newton Protocol, Nava, Predicate, or Inherence.

Established payment and crypto rails still handle settlement. Banks and card networks move fiat payments, while custodians, stablecoin issuers, and blockchains execute or record digital-asset transfers. The profiled companies can authorize or block an agent’s proposed action, but they do not replace the infrastructure that transfers assets and establishes finality.

A pre-execution compliance engine asks whether a proposed transaction satisfies policy before execution. Transaction monitoring asks what happened after execution and whether the activity requires investigation, reporting, or remediation. Screening data can inform the first decision, while monitoring records can enrich the later audit trail. Autonomous finance therefore depends on both functions at different points in the transaction lifecycle.

FAQs

What is a compliance engine for autonomous finance?

A compliance engine evaluates proposed financial actions against identity, authorization, and transaction policies. Inherence applies those policies before execution, while Newton Protocol, Nava, and Predicate use different gating mechanisms. Pre-execution evaluation can stop a prohibited payment before settlement.

What does an audit trail mean for autonomous agent transactions?

An audit trail records each proposed action, policy decision, and execution outcome. Inherence produces a cryptographic receipt, while Nava records verdicts, reason codes, and safety flags. Per-action records let auditors review automated activity without relying on periodic reports.

How does AI compliance for agent payments differ from enterprise AI governance?

AI compliance for agent payments governs financial transactions before value moves. Inherence focuses on transaction-level policy enforcement rather than the model monitoring associated with Fiddler, Zenity, or OneTrust. Transaction controls can enforce spending limits and counterparty restrictions at execution time.

What does a ZK proof receipt verify compared with an attestation or confidence score?

A zero-knowledge proof receipt verifies that a defined policy held without revealing the private inputs. Inherence uses such receipts, Newton Protocol uses network attestations, and t54 Labs produces confidence scores. A verifier can check an Inherence receipt independently instead of trusting a scoring model or validator network.

How does the five-layer stack map to existing screening vendors?

The five-layer stack places screening vendors mainly upstream in identity and compliance data. Inherence can consume verdicts from providers such as Sardine, ComplyAdvantage, Chainalysis, and TRM Labs, then bind those verdicts to enforcement. Existing screening tools can continue supplying risk signals while runtime infrastructure governs whether a transaction proceeds.

The takeaway for this category

Verification mechanism provides the clearest distinction among compliance infrastructure providers. Confidence scores estimate trust, attestations depend on designated validators, monitoring systems preserve records, and zero-knowledge proofs let counterparties verify policy compliance without accessing private inputs. Similar feature lists can therefore conceal different assumptions about who or what establishes a valid decision.

The market will likely support several mechanisms while transaction types and assurance requirements remain varied. Lower-risk payments may accept probabilistic scores or trusted attestations, while regulated or confidential transactions may require independently verifiable evidence. Counterparties may eventually standardize on one approach, or they may combine mechanisms through shared receipt formats and verification interfaces. Near-term adoption will reveal which forms of evidence compliance teams, protocols, and auditors accept across organizational boundaries.