Let an AI assistant prepare the payment. Decide its authority before the rail ever sees it.

What it is

Authority Finality™ before payment finality.

• KYE™ Chain of Authority™. Every instruction carries the traceable chain from the SME owner or authorised role, through the delegated approver, to the AI payment assistant and any tool or sub-agent it used. Accountability stays personal and named; it never transfers to the agent.
• Pre-execution decision. KYE™ resolves the agent’s authority, the payment purpose, the delegated limits, the approval status and the execution boundary, and returns ALLOW, DENY or REQUIRE_APPROVAL with an explicit, supervisory-language reason code. The decision is cryptographically bound to the exact proposed instruction before that instruction can move.
• An approval binds the instruction it was shown. A recorded approval names the payee fingerprint, the amount and the invoice. If the supplier’s bank details change after the approval was recorded, the approval does not cover the changed payee. The instruction is denied, not quietly re-used.
• Evidence Pack™ and outcome receipt. Every decision seals an Evidence Pack™ (inputs, state, applicable rules, Decision Map™, execution-context seal, verification material and outcome) that an auditor or the counterparty institute replays from published keys alone. If the instruction was allowed and reached the synthetic rail, a separate outcome receipt records what happened after execution.

The synthetic workflow

Eight steps, and the rail is the seventh.

1. The assistant receives a synthetic invoice and extracts supplier, amount, due date, invoice number and payment details.
2. The invoice is checked against a synthetic purchase order.
3. The supplier record is validated, including whether the bank details have changed since verification.
4. KYE™ resolves the agent’s authority, payment purpose, limits, approval status and execution boundary.
5. The decision returns ALLOW, DENY or REQUIRE_APPROVAL with explicit reason codes.
6. If permitted, the authority decision is signed and sealed before any execution is attempted.
7. If allowed, the instruction proceeds only to a synthetic rail: no bank, no money.
8. An Evidence Pack™ and an outcome receipt are generated for independent audit replay.

The core demonstrator scenario

Technically processable. Unauthorised on four conditions.

The most persuasive demonstration is not a routine allowed payment but one the rail would happily process. Four conditions, each a rule in the pack, each with its own reason code on the sealed Decision Map™:

All four together: DENY before rail submission, with all four reason codes on the record. Run it against the live decision endpoint, then replay the Evidence Pack™ yourself.

Honest scope

KYE™ governs the agent’s authority and the evidence, not the payment.

KYE™ does not settle payments, hold funds, verify a bank account, or operate a rail. Those remain the functions of the SME’s bank, its payment provider and its own finance controls. What KYE™ governs is the moment an AI agent acts: whether the instruction is admissible, under whose delegation, within which limits, covered by which approval, under which live grant, and with what evidence on the record. That maps to the duties your oversight already sets: strong customer authentication and payee verification under PSD2, operational control of AI systems within declared boundaries under ISO/IEC 42001, accountable and verifiable AI action under the NIST AI Risk Management Framework, data minimisation under the GDPR, and supplier information-security controls under ISO/IEC 27001 — each consumed as a governed authority-and-evidence boundary, never a claim that KYE™ replaces them.

The founding instance is a zero-budget applied-research pilot with a digital-economy institute in Armenia, run on synthetic data only: synthetic invoices, suppliers, purchase orders and instructions; no real SME records, no real customer data, no live bank integration, no real payment execution. No funding, procurement, regulatory approval or endorsement by any central bank, ministry or public body is requested or implied. Production-data admission is a separate, governed second phase with its own obligations: tenant isolation, write-once audit with framework-justified retention, a data-subject access and withdrawal route, a live rail only after authority-before-rail is proven, incident and kill-switch duties, and a monthly joint review.

The pilot

Eight weeks, synthetic data, ending in packs you can replay.

Pilot

For an SME finance team, an open-finance platform, a payment provider or an accounting-software vendor putting an AI assistant on payment operations. Eight-week engagement; synthetic data only.

• Authority matrix: what the assistant may prepare, request, escalate or be denied
• The four-condition core denial plus the ALLOW and REQUIRE_APPROVAL paths, sealed
• Evidence Pack™ examples and outcome receipts replayed independently from published keys
• A policy and technical brief with the second-phase roadmap

Apply (contact for pricing) →

Who it is for

SME owners, finance managers, platform operators, and independent reviewers.

• SME owner. You are the root of the chain. KYE™ makes your delegation explicit (who may approve, up to what, what the assistant may request) and computes every instruction against it, so the assistant helps without quietly acting beyond its authority.
• Finance manager. You approve. KYE™ binds your approval to the exact instruction you were shown, so a payee substituted afterwards is denied rather than paid under your name.
• Platform or payment-provider operator. You run the rail or the accounting stack. KYE™ gives you an authority decision you can require before an agent-originated instruction is accepted, with a sealed pack behind each one.
• Independent reviewer. You answer for the pilot to others. KYE™ gives you packs you verify from published keys alone, without asking KYE™ anything.

Want to run the core scenario on your own authority matrix?

Canonical KYE™ surfaces referenced on this page: Evidence Pack™ · KYE Protocol™.