SEPA Account Activation

SEPA accounts now require an explicit activation call. Completing verification no longer provisions an IBAN on its own — SEPA follows the same activation model as ACH.

Action required. An integration that assumed a SEPA account would appear after KYC will find no account and no IBAN. Add an activation step keyed on the SepaAccount capability status.

What's included

• Standard activation — POST /api/v1/bank/accounts with account_type: "Sepa" orders the account and returns a details_id. The endpoint already served Ach, and also accepts FasterPayment and Spei.
• Activation with wallet linking — when the SepaAccount capability reports ExternalProviderVerificationRequired, the user's Primary Smart Wallet must prove ownership to an external provider first. POST /api/v1/bank/accounts/init returns a challenge and the wallet_address that must sign it; POST /api/v1/bank/accounts/complete submits the signed_challenge and orders the account.
• New capability statuses — SepaAccount can now report ExternalProviderVerificationRequired and ExternalProviderRegistrationPending alongside the existing values.

Requirements

Read the SepaAccount capability from GET /api/v2/user and branch on its status. The two activation paths are mutually exclusive — calling the wrong one returns 400.

Both paths leave the capability in InProgress and return { "details_id": "..." }. The account is usable once the bank account webhook reports the SEPA details.

Limitations

• The chain field on init and complete must be a numeric chain ID sent as a string — "8453", not a chain name. A non-numeric value fails validation, and the resulting error names the field chain_id rather than chain.
• Wallet linking resolves the user's Primary wallet server-side. A user with no Primary wallet cannot complete this path.

Documentation

• SEPA Bank Details
• ACH Bank Details
• Bank Accounts