Auctra
Permission before payment.
A proposed permission layer for banks and wallets to check what an AI agent is allowed to spend—and keep a record of the decision.
Who said it could spend?
Our starting question was how a bank should handle a payment initiated by an AI agent. Human behaviour signals may not fit an automated payer, and identifying the agent alone does not explain whether its owner permitted this particular payment.
Connect each request to a person, a permission, and a record.
The concept focused on Malaysian banks and wallets, with DuitNow, FPX and e-wallet payment journeys as the intended integration context.
the whole journey, at a glance.
Place a permission check between the agent’s request and the bank’s payment decision. The bank keeps customer verification and money movement; Auctra checks the mandate and records the outcome.
The request meets the owner’s rules.
Route the request for human approval.
The request is outside its permission.
A small API with a clear job.
The proposed architecture uses a REST API protected by mutual TLS, short-lived signed credentials, a Python scoring service and PostgreSQL. Each layer answers a different question.
Resolve the agent
Map its signed credential to a verified customer. Check amount, recipient, expiry and whether the mandate has been revoked.
Evaluate the request
Apply explicit rules first, then risk scoring. Return an allow, ask or block response to the bank or wallet.
Preserve the evidence
Write an append-only, hash-chained audit record so decisions can be inspected and changes can be detected.
A conventional database with a tamper-evident log keeps the proposal focused on traceability. Blockchain is not required for this design.
Observe first. Enforce after evidence.
The proposed pilot starts in shadow mode: run alongside a bank’s traffic, record what Auctra would decide, and compare the results before enabling enforcement.
- months 0–3
Identity & limits
Register agents and store customer mandates.
- months 3–6
Guard & ledger
Build the decision engine and test on historical payments.
- months 6–9
Shadow pilot
Log proposed decisions without blocking payments.
- months 9–18
Controlled rollout
Enable enforcement if pilot evidence supports it, then expand.
Start with one institutional partner.
A route into the market
Begin with digital banks and large e-wallets, then commercial banks and gateways. Small businesses would access spending controls through those partners.
A model tied to use
The proposed business combines an institutional subscription with a fee per permission check, plus an optional small-business tier distributed through banks.
What still needs proving.
This is an ideathon concept. The next step would be to test its assumptions with a bank partner.
Demand. How much agent-initiated payment activity exists on the target rails, and where is a permission check most useful?
Decision quality. How often should requests be allowed, escalated or blocked, and can the system meet the bank’s latency needs?
Evidence & obligations. Would the audit record be useful in a payment dispute, and what reviews would the integration require?
A changing ecosystem. How would payment-network standards, including any future PayNet standard, change the integration?