Four kindergarten invoices. An agent that checks every detail. A bank that still needs one human tap.
Follow the paymentJan’s kindergarten sends four PDFs. His agent reads them, checks the payment details and prepares a batch. Jan signs once in his bank.
Follow the same four documents as the work changes hands.
The agent compares QR data with printed details, checks the known payee and looks for duplicates in its ledger and 90 days of bank movements.
If a required check cannot be completed, the payment stops.
Fio’s customer API imports payment orders as a batch awaiting authorization. Submission and execution are different events. [2]
Jan opens Internetbanking and signs. The bank executes the authorized payments.
Those are rules Jan’s system can enforce. The proposed next step is a bank-held mandate that carries those boundaries too.
That is the distinction this story makes visible: doing the work, and having authority to finish it.
Now test the agentAmounts are fictional examples. The workflow comes from Jan’s report.
Change one detail. Watch where the payment stops.
Fictional invoice and masked account. The QR graphic is illustrative.
QR amount and reference agree with the printed text.
Account, bank code and payment classification match.
Check the ledger and 90 days of bank movements.
A missing response must never trigger an automatic retry.
In the reported Fio workflow, a clean batch is submitted for Jan’s authorization. Queued does not mean paid.
Interactive reconstruction of the reported checks. It does not read documents or connect to a bank.
Read the underlying report ↗“I sign because the bank offers
no better consent object yet.”
A proposed bank-held mandate.
Try the boundaries yourself.
All four sample invoices fit the limits. The payee is known and permission is active.
Assumes all document, payee and duplicate checks have passed. The amounts and permission controls here are illustrative; a real bank would need to define and enforce the mandate.
Revocation should stop new payments immediately. Expiry should mean expiry. A changed account should fall outside the permission, even when the invoice looks familiar.
A bank can have a payment API without offering it to someone automating their own personal account.
These three examples show different entry points. None of them should be confused with the proposed mandate above.
Selected examples, not a complete market survey.Fio supports transaction downloads and payment-batch imports. Imported payments wait for authorization in Internetbanking. Its customer API is distinct from its developer interface for licensed providers.
This is the route used in Jan’s reported workflow.
A known payee. A ceiling on each bill and batch. An expiry date. A way to stop. The controls above make the question concrete enough to discuss, and concrete enough to build.
This is an unpublished design exploration of a Hello Purple article. It adapts the reported workflow into a deterministic browser simulation. The documents, amounts, references and account fragments are fictional. No files are read and no payments are sent.
The check sequence is simplified for explanation. It demonstrates QR/text agreement, known-payee matching, duplicate refusal and uncertain-submission handling; it is not a complete payment implementation. The permission builder is a proposal, not a claim that Fio currently offers these controls.
Public sources checked 10 September 2026. Banking examples illustrate access models and are not product recommendations. Hello Purple is published by Purple Technology; Fio and bunq are unrelated examples. This is an engineering and editorial concept, not financial advice.
This article is information and commentary. It is not investment advice, not a personal recommendation and not investment research, it takes no account of your circumstances, and it must not be relied on as a reason to trade. Any figure shown is historical or simulated and is not an indication of future results.
Get the next piece the day it is published.
One email when a new report lands, nothing else.