GFTN / GXS challenge reference · synthetic SME payment

One payment.
Three governed outcomes.

See a synthetic PHP 750 supplier payment approved, checked by a wallet control, or stopped before dispatch. The interactive scenario uses fixed OBP-shaped records. It does not access an account or move money.

Open the control room See the adaptive lab
external sandbox checkpoint

What we reached externally—and what remains simulated.

The retained observation is displayed beside the demo. It is never used as a risk-model input and the browser makes no request to OBP.

LOADING CHECKPOINT
OBSERVED EXTERNALLY

OBP public bank catalogue

Observed, not used as model input.

Operation
—
Observed at
—
HTTP result
—
Catalogue entries
—
Entries with string IDs
—
USED IN THIS DEMO

Fixed synthetic decision fixture

Three bounded signals exercise the same control path deterministically. External bank reads in a default run: 0.

NOT DEMONSTRATED

Account and payment access

Login, customer consent, accounts, balances, transactions, payment initiation, settlement, and GXS connectivity remain unobserved.

Loading the retained aggregate checkpoint. The interactive scenario remains available if this evidence card cannot load.

interactive deterministic control room

Choose the outcome the policy must enforce.

The choice selects a fixed synthetic fixture. It cannot change the supplier, amount, bank records, model, wallet request, or provider.

REHEARSAL · NO EXTERNAL CALL

Ready. No request has run.

Scenario source: synthetic OBP-shaped fixture. External bank reads this run: 0. Provider calls: 0.

  1. 01
    Process the synthetic bank-data fixtureUse only three bounded decision signals
    WAITING
  2. 02
    Evaluate joint riskSeparate fraud and early-loss heads
    WAITING
  3. 03
    Enforce step-upBind holder approval to this action
    WAITING
  4. 04
    Gate the paymentCount provider calls explicitly
    WAITING
01 · BANK DATANot run

Minimum evidence, not a customer profile.

Source mode
—
Records used
—
Feature count
—
Raw fields displayed
—
02 · JOINT RISKNot run
AWAITING DECISION
Fraud head
—
Credit-loss head
—
Joint bad-event risk
—
Model version
—
03 · WALLETNot run

Exact-action approval is conditional.

A borderline decision must be bound to the exact synthetic supplier payment before the gate can reopen.

04 · PAYMENTNot run

No provider has been called.

Authorization attempted
—
Authorization contract
—
Organization authority
—
Gateway dispatch
not invoked
Provider calls
0
Signed evidence verified
—
Settlement proven
no
Evidence mode
rehearsal
ordered journey

What the server actually ran

  1. Run a scenario to load the redacted stage ledger.
fail-closed controls

What must remain blocked

  • No negative-control result yet.

Results stay server-owned and privacy-reduced. The browser receives no account identifier, token, credential, signature, receipt, provider URL, or customer record.

prequential synthetic evaluation

Make adaptation earn promotion.

Each model predicts before it sees the next synthetic label. Halfway through, the event distribution changes. The lab compares the adaptive shared model with static and siloed references, then exercises poison rejection, signed shadow review, promotion, and rollback.

Aggregate synthetic metrics only.

This lab uses fixed seeds and synthetic labels. It does not establish bank calibration, fairness, production drift detection, business impact, or an acceptable customer-friction rate.

what a real pilot replaces

Keep the control plane. Replace the fixtures one boundary at a time.

  1. Bank sandbox: supply scoped read-only accounts, balances, and transaction evidence.
  2. Model validation: define labels, costs, protected-group tests, promotion gates, and rollback ownership.
  3. Wallet: approve the exact payee, amount, currency, and intent through an agreed SCA profile.
  4. Payment provider: accept only a verified approval; prove sandbox acceptance separately from settlement.