GFTN-style SME banking campaign · verified local execution

Thirteen scenarios.
One honest boundary.

Follow one synthetic business payment from organization authority and minimized account evidence through approve, exact-action step-up, decline, provider ambiguity, reconciliation, and model governance.

Inspect the 13 scenarios What still needs me?
one payment · complete control story

From “may this business act?” to “what did the provider say?”

The campaign uses a synthetic PHP 750 SME payment for the GFTN path and a separate EUR 1,500-over-1,000-cap negative control.

  1. 01
    AuthorityBusiness and delegated officer
  2. 02
    Bank evidenceThree minimized features
  3. 03
    RiskApprove · step-up · decline
  4. 04
    Exact paymentVoP · SCA · payee · provider
  5. 05
    DispatchOne mutation, never a blind retry
  6. 06
    EvidenceSigned result and reconciliation
executable evidence matrix

All thirteen local scenarios passed.

Open a scenario to see the evidence and the limit of the claim.

13 / 13 LOCAL PASS
01Business authorityKYB-shaped trust gatePASS

Bundled GLEIF testnet evidence is verified offline and connected to bounded officer and agent authority.

Not production QVI issuance or legal bank onboarding.

02Data minimizationAccounts · balances · transactionsPASS

Three OBP-shaped read invocations become three bounded risk features. Raw feature values remain undisclosed and the payload vault path is exercised.

Synthetic records, not customer-consented account access.

03Low-risk approveExact PHP 750 paymentPASS

Risk, organization authority, PaymentAuthorization v1, provider request, delegation and signed-receipt gates all verify.

Authorization evidence is not provider acceptance.

04Wallet step-upBorderline decisionPASS

The payment blocks first. A pinned local holder key signs the exact payment, validates OID4VP transaction data, and unlocks a fresh authorization.

Local holder fixture, not external-wallet regulated SCA.

05High-risk declineStop before dispatchPASS

No payment authorization is issued and no checkout or gateway dispatch is attempted.

This proves control behavior, not model accuracy.

06Spend-cap denialEUR 1,500 > EUR 1,000PASS

The delegated agent is denied when the payment crosses its bounded authority.

Local policy enforcement, not a bank-side payment limit.

07Authority revocationSame purchase, changed authorityPASS

The first delegation verifies; after revocation, the same purchase is denied.

Not a production revocation registry or legal termination.

08Exact-payment contract40 signed mutationsPASS

Amount, currency, payee, VoP, consent/SCA, provider request, risk, idempotency and organization-authority substitutions all fail closed.

A commitment binds evidence; it does not make the evidence true.

09Replay and tamperCaptured evidence is not reusablePASS

Risk, wallet and payment-authorization replay, payment substitution, receipt tamper and attacker re-signing are rejected.

Not transport-level exactly-once settlement.

10Provider idempotencyAccepted responsePASS

One provider mutation is recorded. The identical replay resolves from state with zero second mutations and signed evidence verifies.

The provider is a deterministic local fixture.

11Ambiguous outcomeTimeout without blind retryPASS

A timed-out dispatch becomes outcome_unknown. Repetition does not issue another mutation.

No real provider timeout or callback was observed.

12Read-only reconciliationObserve, do not resubmitPASS

One read-only lookup resolves the ambiguous state; mutation calls during reconciliation remain zero.

Local recovery mechanics, not bank settlement evidence.

13Model governanceShift · shadow · promote · roll backPASS

Poison and feedback-replay attempts fail. Signed shadow gates pass, a reviewed promotion runs, and the kill-switch rollback is exercised.

Synthetic measurement, not bank calibration or performance.

external sandbox ladder

Two steps are ready for you—not for the agent.

The implementation exists, but your account, consent, credential, or explicit provider action is the authority boundary.

HUMAN AUTHORIZATION REQUIRED
OBSERVED EXTERNALLY

OBP public catalogue

A dated unauthenticated GET checkpoint returned HTTP 200 with 226 catalogue entries on 25 July 2026.

Account access
No
Consent used
No
Payment executed
No
HUMAN GATE 01

Authenticated OBP read

Read one sandbox account, balance and transaction set into the same minimized three-feature boundary.

Your actions

  1. Own and log into the sandbox account.
  2. Choose the account/view and establish consent.
  3. Place the six required values in local protected configuration.
  4. Review the preflight and personally authorize --read.
Agent boundaryMay validate configuration shape and evidence. May not log in, consent, or use your identity.
HUMAN GATE 02

Brankas Direct checkout

Create one PHP sandbox checkout only after the approved exact-payment gate.

Your actions

  1. Own the Brankas sandbox organization.
  2. Configure destination account, API key and HTTPS return/fail URLs.
  3. Personally authorize creation of one test checkout.
  4. Open Tap and complete bank selection, consent, login and test TFA.
Agent boundaryMay verify the redacted receipt. May not create the checkout or complete the hosted bank flow.
reproducible local evidence

Run the same campaign from one command.

The runner blocks socket use, reads no provider credential, launches no browser, and returns a public-safe matrix.

cd "/home/kaali/crazy idea"
PYTHONPATH=src:. python3 \
  scripts/run_banking_sandbox_campaign.py