Sending EUR to accounts not held in your user's name
Payment Accounts also enable outgoing SEPA transfers to third parties. The mechanics are the declared-beneficiary flow: whenever the destination account is not held in your user's own name, the beneficiary's name is declared up front and screened before funds move.
Whitelisted third-party beneficiaries
Whitelist Destination IBAN (POST /wallets/whitelist-iban, and its business equivalent) accepts an optional name field (1–70 characters) — the declared name of the third-party account holder. Supplying name marks the beneficiary as third-party and triggers sanctions screening of the declared name.
Beneficiaries whitelisted without a name (the user's own external accounts) behave exactly as before.
Without Payment Accounts enabled, supplying name is rejected with Third-party payouts are not enabled for this application.
Ad-hoc third-party payouts
Initiate SEPA Payment (POST /wallets/send/initiate/bank) with a raw destination (destination.iban + destination.bic) accepts an optional name (1–70 characters, mutually exclusive with whitelistedIbanId) declaring the third-party beneficiary.
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.
Interaction with trusted beneficiaries and SCA
Nothing changes: SCA rules, trusted-beneficiary exemptions, and the existing whitelist lifecycle (deactivate, trust/untrust) apply to third-party beneficiaries exactly as they do to first-party ones.
Trying it out
You can simulate the full third-party payout flow — whitelist with a declared name, initiate, confirm, and drive the payout status — on the sandbox environment. See Testing in Sandbox.