The short answer
Bankproof is the name for five fixed controls and a stop rule: input, authority, approval, exception and evidence. The workflow stops as soon as something falls outside those rules. It is a way of working from practice, not a certification and not an approval by any bank.
Where the name comes from
I come from work at one of the largest banks in the Netherlands, where no automated step exists without a recorded input, authority, approval, exception route and evidence. I put those five rules into every SME workflow. I call that the Bankproof method. That is why my workflow stops at a deviation instead of guessing, and why nothing lingers in a pilot: at the agreed review points you decide on evidence, and a no-go also comes in writing. And I do not build what your package already does.
The five controls, and which failure each one prevents
| Control | The question | Which failure it prevents |
|---|---|---|
| Input | Which sources may the workflow read and how is input checked? | A decision on a wrong or outdated source, or on instructions hidden inside a document. |
| Authority | What may AI propose and what may it never do? | An email sent or a booking made that nobody wanted. |
| Approval | Who checks, against which criterion, before the step to the outside world? | A check nobody performs because it does not fit the work. |
| Exception | When does the workflow stop and who takes over? | A deviation that runs on silently and only surfaces at the customer. |
| Evidence | What is recorded per case? | Being unable to show afterwards what happened. |
The stop rule
The workflow stops the moment something falls outside the rules. That is not a feeling the model has but a rule in code: a missing field, an amount that does not add up, a source that is not on the list or a case that looks too little like the test cases. The case goes to the exception queue, with the reason attached, and an employee takes over. Amounts and thresholds are checked by ordinary code, not by the model.
The package first, then the build
If Exact, AFAS, Copilot or Gemini already covers the step, the advice says "switch this on" and I do not build it. I only build the workflow that is left between your mailbox, a second system and the package. See what each package already does.
Design before build: the control card
Before a single line of code, there is the control card: per process the source, what AI prepares, who approves, the stop rule and what is recorded. You get that card in outline in the free AI plan and per process in the audit. You can also fill it in yourself with the control card on this site.
Deciding on evidence, not on a demo
A baseline first, a first working version in week one, and the AI Operating System lets you stop after week one at the agreed price. Then a final measurement next to the baseline. If it does not work as agreed, I fix it or you get your money back. The choice is yours. A no-go also comes in writing. See the prices and limits.
What Bankproof is not
Not a certification, not a quality mark and not an endorsement by a bank. Not a guarantee that a workflow is "AI Act compliant" or "GDPR proof"; that judgement depends on the specific processing, see security. Not a promise that AI is never wrong. It is the agreement that an error stops, is visible and has an owner.
Frequently asked questions
What makes you different from other AI agencies?
I come from work at one of the largest banks in the Netherlands, where no automated step exists without a recorded input, authority, approval, exception route and evidence. I put those five rules into every SME workflow. I call that the Bankproof method. That is why my workflow stops at a deviation instead of guessing, and why nothing lingers in a pilot: at the agreed review points you decide on evidence, and a no-go also comes in writing. And I do not build what your package already does.
