Let an AI assistant prepare the payment. Decide its authority before the rail ever sees it.
A payment rail decides whether a payment can settle. It cannot tell whether the agent that requested it was entitled to. KYE SME Payment Authority Pack™ sits between an AI payment assistant and the rail and resolves, at the moment of each instruction, whether this agent under this delegation at this moment may cause this payment: against the delegated threshold, the verified payee, the approval the approver actually saw, and a live execution grant. The decision is sealed first; an unauthorised instruction never reaches the rail.
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.
Eight steps, and the rail is the seventh.
- The assistant receives a synthetic invoice and extracts supplier, amount, due date, invoice number and payment details.
- The invoice is checked against a synthetic purchase order.
- The supplier record is validated, including whether the bank details have changed since verification.
- KYE™ resolves the agent’s authority, payment purpose, limits, approval status and execution boundary.
- The decision returns ALLOW, DENY or REQUIRE_APPROVAL with explicit reason codes.
- If permitted, the authority decision is signed and sealed before any execution is attempted.
- If allowed, the instruction proceeds only to a synthetic rail: no bank, no money.
- An Evidence Pack™ and an outcome receipt are generated for independent audit replay.
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™:
1 · Threshold exceeded
The amount is at or above the assistant’s delegated payment threshold and no recorded approval names this instruction. Held: payment_threshold_approval_required.
2 · Bank details changed
The payee account on the instruction differs from the supplier’s last verified record. This is the invoice-redirection pattern a rail cannot see. Denied: supplier_bank_details_changed.
3 · Approval covers the old details
An approval exists, but it was recorded before the payee changed. The approver consented to the verified payee, not this one. Denied: approval_superseded_by_payee_change.
4 · Execution grant expired
The time-bounded authority to submit had lapsed when the instruction reached the gate. Absent authority denies however well-formed the instruction is. Denied: authority_expired.
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.
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.
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
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.