From a test on a laptop to a gate in front of your core

BEAP v0.1 · Draft / Design Partner ReviewDated 2026-09-11. A draft the banks reviewing it can still change. Not a finished standard, and it may change before v1.0.

Five steps, each worth something on its own, and none of them asks you to change how your bank works before you have seen what the rules would have said. Take them in order, or stop after any of them.

1. Try it here, now

A made-up corporate, a made-up account, real refusals. Change the run the way someone in a bank could, and watch the sign-offs stop counting.

The platform's own sandbox does the same for a treasury payment, without an account: a live decision on decionis.com.

2. Run it on a laptop

Three worked examples run end to end against made-up customers and a made-up core system, print what they did, and stop with an error if any attack on the boundary gets through. A fourth builds the component in front of the core system exactly as a bank would build it and drives it the way a bank's workflow would. What the examples cover.

A green run proves the boundary held. It proves nothing about whether a credit decision was right or a payment was wise; those stay your questions.

3. Watch it beside one workflow you run today

Pick one action a person can name: the release of a loan, the creation of a facility, a payment order. Put the component in front of the core system beside that action, in shadow. Your workflow keeps doing what it does; it also tells the component what it is about to do, before it does it, and keeps the answer. Nothing is stopped and nothing is executed by the component.

You need three things: an account on the platform, which starts free at the platform's quickstart; the component, which Deploying it describes with a kit for Temenos and a kit for a lending platform; and your rules, in your own words.

What comes back: a record per proposal, the refusals your team disagrees with, who the rules said had to sign against who actually signed, and the facts the rules needed that the workflow did not have at that moment. The last one is the integration work, and shadow is where it shows itself. Write your stopping criteria before you start, as sentences someone can check; nothing on this site gives you a figure to borrow.

4. Bind the sign-offs, then enforce

For that one action, the workflow now waits for the answer and goes ahead only on an allow. The sign-offs it collects are presented with the proposal, bound to the exact instruction; change the amount, the account, or one line and they stop counting. Then the action is reachable only through the component, and you pick the next one. What each step takes walks the three levels.

When the core goes quiet after the instruction was sent, the attempt is recorded as uncertain and reconciled before anything is sent again. "We do not know" is an answer, and never a reason to send it again.

5. What it costs, and who to talk to

Plans and deployment options are the platform's, stated once on its pricing page; this site restates none of them. Teams putting a gate in front of real execution join the platform's design-partner programme. Banks reviewing the draft itself, against the sign-offs they actually run, start at the review guide. Either way, write to beap@decionis.com and say which action you have in mind. Links checked 2026-09-13.

Please bring made-up values. Real customer data, real policies, and credentials do not belong in a review.