Agentic Payments

A payment processor moves money from sender to receiver. An execution engine does that — and also holds funds while conditions are evaluated, queries external registries or data sources to determine the correct beneficiary and amount, splits disbursements across multiple parties, and documents every decision. PayKeeper’s licensed escrow structure provides the legal framework that makes fund-holding and conditional release binding, not just contractual.

A subledger is a detailed record that sits beneath a general ledger entry — it tracks the specific obligation behind a payment, not just the money movement itself. When that subledger record is tokenized, it means each invoice, contract, or obligation is assigned a unique digital identifier that travels with the payment. PayKeeper uses that token to match incoming funds to the exact obligation they are meant to settle, retrieve the verification data associated with that obligation, and execute disbursement logic that is specific to it. Without the token, a payment is just a number and an amount. With it, the payment carries the context PayKeeper needs to act on it intelligently.

Yes — and this is one of the defining characteristics of the use cases PayKeeper is built for. In a conventional escrow, both parties are identified upfront. In a registry-linked flow, the beneficiary may be unknown at funding time because the receivable has not yet been sold, or because the secondary-market transaction that transfers ownership has not yet settled. PayKeeper holds the funds in escrow while that process completes, then queries the registry at the moment of settlement to identify the current holder. The escrow agreement defines the registry query as the determinative mechanism — rather than requiring both parties to be named at the outset.

This is a split-disbursement scenario, and PayKeeper is specifically designed to handle it. The disbursement logic encoded in the arrangement agreement — informed by the registry data returned at settlement — specifies the priority and proportional share of each claimant. Senior claims are satisfied first; the residual flows to junior holders. Each disbursement is documented independently. If the incoming payment is insufficient to satisfy all claims, the waterfall logic determines what each party receives and what amount, if any, is held pending further receipts.

PayKeeper’s escrow structure protects all parties in this scenario. Rather than releasing funds to an unverified party, PayKeeper holds the funds pending resolution. The exception-handling protocol — defined in advance in the arrangement agreement — specifies how conflicting ownership claims are escalated and resolved. No disbursement occurs until the correct beneficiary is definitively established.

PayKeeper provides an API that can be called by ERP systems, accounts-payable platforms, marketplace back-ends, and AI-agent commerce infrastructure. The payer’s system initiates the escrow funding via API or standard payment instruction; PayKeeper handles all downstream logic. On the beneficiary side, disbursement confirmations and reconciliation data are returned via webhook or API callback, allowing receiving parties to update their accounts-receivable records automatically. For platform operators building PayKeeper into their product, the API is the primary integration surface — no manual workflow is required once the arrangement and registry connections are configured.

Smart contracts can encode conditional release logic and execute it without intermediaries — and for purely on-chain transactions with parties comfortable operating in that environment, they work well. PayKeeper’s execution engine differs in three important ways. First, it operates under a licensed escrow framework, which provides legal enforceability and regulatory oversight that a smart contract alone does not. Second, it can query off-chain registries and real-world data sources — a receivables clearinghouse, a government invoice registry, a third-party verification API — which smart contracts cannot do natively without oracle infrastructure. Third, it handles fiat currency, bank transfers, and stablecoin rails interchangeably, accommodating parties who cannot or will not operate in a pure crypto environment.

PayKeeper’s escrow license is issued in the State of Utah (NMLS 2401821). For international arrangements, PayKeeper engages licensed local partners in the relevant jurisdiction to provide the regulated fund-custody function, while PayKeeper provides the execution logic, registry integration, and compliance infrastructure. All arrangements are subject to applicable local laws, cross-border sanctions screening, and legal review by qualified local counsel.

All flows through PayKeeper are subject to KYB/KYC verification of all parties, OFAC and international sanctions screening at initiation and disbursement, and AML monitoring. For cross-border flows, additional screening against UN Security Council sanctions lists and applicable local regulatory requirements applies. PayKeeper does not process payments involving sanctioned persons, entities, or jurisdictions.

Every event in a PayKeeper-managed flow is logged with a timestamp, the identity of the triggering party or system, the data inputs (including registry query responses), and the resulting action. This log is immutable within PayKeeper’s infrastructure and is available to the parties to the escrow arrangement through the platform dashboard and API. For regulatory examinations, PayKeeper can produce the complete event log for any transaction within its retention window. For dispute resolution, the log provides an unambiguous record of what data was available at the moment each decision was made — removing the factual uncertainty that makes payment disputes difficult to resolve.