Sandbox test personas
The seeded customers you test against. Everything on this page is fictional: invented companies, invented IBANs in a reserved test range, and money that exists only in the sandbox.
Use these IBANs directly. Do not invent one — payments are persona-to-persona (see sandbox), and a creditor outside this list is refused. That refusal is correct behaviour and looks exactly like a bug in your client, which is why this page exists.
The three personas
| Persona | IBAN | Balance | Use it for |
|---|---|---|---|
| Sandbox Trading Oy | FI7479400095000001 |
€12,500.00 | General AIS: balances, transactions, multi-call sequences |
| Sandbox Low Balance Oy | FI4779400095000002 |
€4.50 | A fundsAvailable: false answer, and insufficient-funds payment refusals |
| Sandbox Instant Oy | FI2079400095000003 |
€8,000.00 | Instant SEPA initiation, persona-to-persona |
Each holds one EUR account. Balances are topped back up to the figures above every night, so a persona you drained yesterday is usable again today. Your own test payments move them during the day, so treat the figures as a starting point rather than a constant to assert on — and if you need a persona at full balance mid-session, do not wait for the sweep: use a different one.
Completing SCA
A person completes this step. The credentials below are published so you
never have to ask us for one, but the sign-in form is the customer portal’s own,
and it is protected by bot detection — so a script driving it headlessly will be
stopped there. Point a human at the scaRedirect link, or drive it in a browser
you are sitting at.
We would rather say that plainly than have you discover it. An earlier version of this page claimed the ceremony completed “without a human”; it does not, and automating past an ASPSP’s bot protection is not something a provider should be doing.
The ceremony is password + one-time code, so you need both. All three personas share the same password, and every persona uses the same static code:
| Persona | Sign-in email | Password | One-time code |
|---|---|---|---|
| Sandbox Trading Oy | trading@sandbox-persona.local |
SandboxPersona!2026 |
000000 |
| Sandbox Low Balance Oy | lowbalance@sandbox-persona.local |
SandboxPersona!2026 |
000000 |
| Sandbox Instant Oy | instant@sandbox-persona.local |
SandboxPersona!2026 |
000000 |
Follow the scaRedirect link from a consent or payment creation, sign in as the
persona, and enter the code. That completes the ceremony.
Published deliberately, on the same reasoning as the demo client key: these authenticate fictional companies holding fictional money in a reserved IBAN range, they are seeded only in the sandbox, and they are shared by everyone who reads this page — so publication takes away no capability. Production SCA is a real ceremony with a real code sent to a real person, and none of this reaches it.
The creditor name matters
Verification of Payee is real in the sandbox, so creditorName is compared
against the persona’s registered name above — not accepted as given. Send the
name exactly as written in the table to get a match.
Sending anything else is the cheapest way to exercise the warning path deliberately: the customer is shown a mismatch and must accept it before they can approve. That is the correct production behaviour, not a sandbox peculiarity.
What these personas are not
- Not real customers. The companies do not exist. The registration numbers are structured to be obviously synthetic.
- Not reachable from production. The IBANs sit in a reserved test range that the clearing filter refuses, so a payment to one of them cannot leave the sandbox even if a production client sent it.
- Not stable across resets. The identities and IBANs above are seeded and will not change silently — but transaction history and balances are rebuilt whenever the sandbox resets. Do not build long-lived state against them.