Third-Party SEPA Payouts

Payment Accounts also enable outgoing SEPA transfers to third parties. The model: every payout destination carries a declared payee — the user's own account, or a third party by name — declared once, verified against the payee's bank, and screened before funds move. A destination without a declared payee cannot be paid: the payout is refused with errorCode: "30080".

Declaring the payee

At whitelisting — Whitelist Destination IBAN (POST /wallets/whitelist-iban, and its business equivalent) accepts the payee declaration alongside iban + bic:

Field	When	Meaning
`ownAccount: true`	The user's own external account	Verified against the user's legal name — no other fields allowed
`beneficiaryType`	Third party	`RETAIL` or `CORPORATE`
`firstName`, `lastName`	Third party, `RETAIL`	The individual payee's names
`name`	Third party, `CORPORATE`	The company name (1–70 characters)

On existing rows — IBANs whitelisted before Payment Accounts have no declared payee. Declare one once via POST /wallets/whitelist-iban/payee with { userId, whitelistedIbanId } plus the same declaration fields. Until then, payouts to those rows refuse with 30080.

Ad-hoc — Initiate SEPA Payment (POST /wallets/send/initiate/bank) with a raw destination (destination.iban + destination.bic) accepts the same declaration fields for a one-off payout.

A declared payee is permanent for that row: declaring a different payee on the same row is refused. Repeating the identical declaration is accepted and changes nothing.

Verification of Payee

Declaring a payee runs the SEPA Verification of Payee check against the payee's bank. The result is returned on the row (and on every later read) as:

"vop": { "status": "MATCH", "matchedName": "...", "checkedAt": "..." }

`vop.status`	Meaning	What to do in your UI
`MATCH`	The declared name matches the account's holder	Proceed
`CLOSE_MATCH`	Almost — the bank returned the corrected name	Show `matchedName` to the user; the payment order and screening use the corrected name
`NO_MATCH`	The name does not match the account's holder	Warn the user clearly before they authorise
`UNAVAILABLE`	The scheme could not answer	Recorded; proceed with care

Verification of Payee never blocks saving the payee — the user decides whether to proceed when they authorise the payment with SCA. No provider identifiers are exposed. Accounts on the platform itself cannot be whitelisted (errorCode: "00013" — use intra transfers).

Authorising the payment

Every payout from a payment account is confirmed with strong customer authentication: initiation returns a challengeId, and Confirm Transaction requires the verification code and the end user's ip. Confirmation codes are dynamically linked to the amount and payee; a wrong code is refused (31064), attempts are limited, and challenges expire after five minutes. Users may designate trusted beneficiaries under SCA. See the SCA reference for factors (sms, totp, passkey).

Users without recorded consent on an enabled application cannot make third-party payouts at all (403 / 31128) — see gating. Their payouts to their own external account are allowed once Verification of Payee confirms the account holder's name is theirs; this check runs automatically at initiation.

SEPA Instant sending limits

Users can set per-transaction and daily SEPA Instant sending limits, changed only under SCA:

POST /wallets/sepa-instant-limit — request a limit change (returns a challenge)
POST /wallets/sepa-instant-limit/confirm — confirm with the verification code
POST /wallets/sepa-instant-limit/status — read the current limits and any pending request
POST /wallets/sepa-instant-limit/resend-otp, POST /wallets/sepa-instant-limit/cancel-request

(Business equivalents live under /wallets/business/sepa-instant-limit….) A payment above the limit is refused at initiation with errorCode: "30145".

Fees

Payout fees are charged on top of the payment amount: the payee always receives the full principal, and the paying account must cover amount + fee.

What to display to users

Rely on the existing SEPA_PAYOUT_INITIATED / SEPA_PAYOUT_COMPLETED / SEPA_PAYOUT_FAILED webhooks for state (see Bank Transfer Webhooks); their types and payloads are unchanged. On a CLOSE_MATCH payee the payout and statement carry the bank-corrected name.

Errors to handle

Code	Meaning
`31128`	The user has not accepted the Payment Account terms (third-party EUR blocked)
`30080`	The destination has no declared payee — declare it first
`30145`	Above the user's SEPA Instant sending limit
`31064`	Invalid SCA verification code
`00013`	IBAN already whitelisted, or belongs to an internal account

Trying it out

You can simulate the full third-party payout flow — payee declaration, every Verification of Payee outcome, initiate, SCA confirm, and the payout status — on the sandbox environment. See Testing in Sandbox.