Reports · The Map
Hand the agent
the company account.
One key lets an agent pay suppliers, close the books and collect from customers. Compose a payment, watch what happens, and find the one step a person still takes.
The permission, as shipped6 alone · 2 person · 1 later · 3 absent
The twelve things a business asks of its money
Agent
Person
Later
Absent
List wallets, read a balance
Read transactions
Pay another Walletory wallet
Pay a bank account abroad
Pay a Singapore bank account
Convert currency in a payment
Ask a customer for money
Approve it, release the money
Cancel an unanswered request
Be told when it settles
Issue a scoped or expiring key
Revoke the key
count
6
2
1
3
Read from the specification and its documentation. Section 04 names the endpoint behind each row.Open the full matrix
The Map
Interactive edition · 5 min
01Two doors
Same agent. Two sides of the money rail.
In the first report an agent prepared four invoice payments and a person signed once. Here the same question is asked of a business account that was built to be operated by software.
Property
Personal account · a Czech bank
The agent prepares. I sign.
Business account · Walletory, Singapore
The agent holds the key.
Credential
A token the account holder creates in web banking
A bearer key issued by hand, usable only from pre-approved IP addresses
Reads
Movements, 90 days without extra authentication
Wallets, interim available balance, transactions in 90-day windows
Sends
A batch that waits under “payments awaiting authorization”
Wallet-to-wallet; SWIFT, SEPA, Japan and Philippines local
Who says yes
The account holder, on every batch
Nobody, for outgoing payments. The customer, for a payment request.
Duplicate protection
None on the API. The agent keeps its own ledger.
None in version 1: the same request sent twice creates two payments. Version 2 requires an x-idempotency-key header that stops the repeat.
Permission model
Queue for signature, or full automation with extra signing hardware. Nothing between.
Version 1: one key, every endpoint, no scopes, no expiry. Version 2 adds scoped access.
Human steps per run
1 human step per run
0 human steps, until the money is someone else’s
Left column from the published report and Fio’s customer API documentation. Right column from the Walletory Business Customer API specification and documentation. Disclosure: Purple Technology, which publishes Hello Purple, and Walletory share some owners.
02Compose a run
Pick a payment. Watch every call the agent makes.
Every step is what the real API does, told in plain words. The names, amounts and timings are made up. Flip a condition to see where the payment stops, and who was needed.
The payment
Conditions
Simulated run · version 1 · nothing is sent anywherePersonal account, for comparison: 1 human step per run
0steps0by the agent alone0human steps·outcome
#What happensWho acted
Choose a payment and run the agent. Each call appears here as it would be made.
03The question everyone has
How can I feel safe handing my agent the key?
Honestly: partly because of what Walletory holds, and partly because of rules you have to give the agent yourself. Here is which is which, and what a mistake could cost with and without those rules.
Walletory holds this for you
The account’s own guards
- The key works only from the computer addresses you register. A leaked key is useless from anywhere else.
- Walletory never stores your key, only a fingerprint of it, and it checks that fingerprint on every request.
- Every request is logged, so there is always a record of what the agent asked for and when.
- Money asked of a customer moves only when that customer says yes, on their own device, with two-factor.
- Ask Walletory and the key is switched off.
Your agent must hold this
The rules you give it
- A list of payees it may pay, and nobody else.
- A ceiling per payment and per day.
- A ledger of what it has already paid, checked before every payment.
- A rule to stop and ask a person when an outcome is unclear, never to retry blindly.
- A person who reviews anything above an amount you choose.
Not on the account yet
What the key cannot do for you
- It cannot be read-only.
- It cannot be limited to one wallet.
- It cannot carry a spending ceiling.
- It cannot expire on its own.
- It does not catch the same payment sent twice. Version 2 does, with an idempotency key.
- Scoped access, so a key holds only what it needs, is planned for version 2.
The worst a single mistake could cost
A made-up euro wallet holding 19,740 euro. Switch the agent’s rules on and off.
19,740 euro, to anyone, tonightWith the key and no rules, a bad invoice or a bug can empty the wallet to any account in the world before the office opens. The account will not stop it.
Walletory’s guards stay on whichever way you switch these: a stolen key still does nothing from another computer. Amounts are illustrative.
04What the key permits
What the agent does alone, what a person does, what is not on the API.
Every row is a thing a business might want its agent to do. The dot says who can do it today, reading the specification literally.
| Action | Agent alone | A person | Coming later | Not on the API | Where it says so |
|---|---|---|---|---|---|
| List the business’s wallets and read a balance | GET /accounts, GET /accounts/{AccountId}/balances | ||||
| Read transactions for reconciliation | GET /accounts/{AccountId}/transactions, 90 days per call, UTC | ||||
| Pay another Walletory wallet | POST /domestic-payments | ||||
| Pay a bank account abroad (SWIFT, SEPA, JP, PH) | POST /international-payments; the rail is chosen from country and currency | ||||
| Pay a Singapore bank account | Planned for version 2; today the domestic endpoint is wallet-to-wallet only | ||||
| Convert currency as part of a payment | CurrencyOfTransfer must equal the wallet currency | ||||
| Ask a customer for money | POST /payment-requests, debtor by SG.Walletory.Email | ||||
| Approve that request and release the money | The debtor, in their own Walletory account, existing accept flow with 2FA | ||||
| Cancel a request the customer has not answered | DELETE /payment-requests/{id}, only while PDNG | ||||
| Be told when a payment settles | No callback in the spec; status is read by GET | ||||
| Issue itself a read-only or capped key | No scoped keys in version 1; version 2 is designed with scoped access | ||||
| Revoke the key | Keys are manually generated and revoked |
the agent, with the key, from the approved addressa named personplanned for version 2not in the specification
05Sources & method
What is real here, and what is a reconstruction.
From the specification
- Every endpoint path, HTTP method, field name, identification scheme and status code shown in the run and the matrix, from the Walletory Business Customer API OpenAPI specification (version 1.0.0, as circulated in January 2026) and its documentation pages (last edited 2026-08-27).
- The per-rail required fields for SEPA, SWIFT and Japan local, from the “International Payment Requirements by Payment Method” table.
- The authentication model: bearer key, IP allowlist, HTTPS, hashed storage, manual issue and revocation, no expiry, no scopes (version 1).
- What differs in version 2, now in development: an x-idempotency-key header that stops duplicate payments, scoped access, and payments to Singapore bank accounts. From Walletory’s review, September 2026.
- The pull-payment lifecycle PDNG, ACTC, ACSP or RJCT with StatusReason; approval in the customer’s own Walletory account with 2FA; cancellation only while PDNG; 429 on too many pending requests to one debtor. The payment-request endpoints are in the documentation (June 2026) and not yet in the January specification file.
- The error envelope: an Errors array with ErrorCode, Message and Path, using Open Banking error codes.
- The left door: the published report “The agent was ready. The bank wasn’t.” and Fio’s customer API documentation.
Simulated or inferred
- Wallet identifiers, payment identifiers, amounts, beneficiaries, IBANs and BICs are fictional. The German IBAN is the format example published by banks, not an account.
- Response timing and the passage from PDNG to a final status are animated; a real payment takes as long as the rail takes.
- The exact wording of error messages for a currency mismatch and for cancelling an accepted request is not in the specification; the run shows the documented HTTP code with an illustrative message in the documented envelope.
- The run models version 1, which has no duplicate protection: an identical repeat is shown as a second payment.
- Two fields shown come from the newer documentation and are absent from the January specification: the international status ACWP, and NameKana under SupplementaryData.Creditor for Japan. Where the two disagree, the run follows the documentation.
- Nothing here connects to Walletory. No key, no network call, no account.
- This page describes engineering. It is not financial advice and does not offer or invite the use of any payment service.