๐ณ You can now stop a physical card from renewing automatically, without canceling it. Call the new cancelPhysicalCardRenewal mutation while the card is in the ToRenew status. The card remains active until its expiry date, then expires rather than being renewed and reissued.
๐ฆ You can now add multiple cards to Apple Pay or Google Pay with the new addDigitalCards mutation. It works like addDigitalCard, but it requires only a single consent flow for the entire batch.
๐ You can now control public onboarding links separately for creating and updating accounts. If you've already turned on public links, both are on by default โ adjust them anytime in your Dashboard under Onboarding > Public links.
\n๐ All accounts closed before 2 April 2026 now use the 2026 closure reason codes. All your accounts use the same codes, so you can run data analysis across your full history.
\n๐ All capital deposits canceled before 2 April 2026 now use the 2026 cancelation reason codes. As with closures, all your capital deposits use the same codes, so you can run data analysis across your full history.
\n๐ฉ You can now see how your onboarding and Know Your Customer (KYC) email notifications are configured, from your Dashboard under Settings > Notifications. The following notifications are now visible:
\n๐ You can now filter virtual IBANs by status โ Enabled or Canceled โ with the status filter on virtualIbanEntries in the account query. This makes it easy to surface only Enabled IBANs, even when an account has many virtual IBANs.
๐ You can now create a capital deposit case for companies whose legal name is longer than 100 characters. The limit on the companyName, accountName, and name fields has increased to 255 characters (previously 100), matching standard French registry formats. No changes needed on your end.
๐ The conditions for an account to move from Closing to Closed status are changing. Before an account can close, all of the following must be true:
Booked balance is zero.Upcoming or Pending status, for any payment type (new).Because of these changes, accounts may stay in Closing status longer than before. If your integration tracks closure timing, adjust your expectations accordingly.
๐ Incoming credit transfers to a Closing account are now accepted when the booked balance is negative. This helps settle outstanding debts before the account is Closed. Transfers to Closing accounts with a zero or positive balance are still returned to the sender, as before.
โ ๏ธ The DormantAccount closure reason is deprecated. Inactivity replaces it, with the description: \"Prolonged inactivity according to local regulatory definitions or internal policy.\" All accounts that previously used the DormantAccount closure reason are now using Inactivity.
If your integration filters, displays, or processes closure reasons by code, update it to handle the new code Inactivity and remove any reference to DormantAccount. See the updated closure reason codes and deprecated reason codes for the full mapping.
๐งญ Starting June 4, Standing Orders execute on their lastExecutionDate value. For example, a Standing Order with lastExecutionDate set to January 10 now runs on January 10 itself.
๐ก๏ธ Starting May 25, Single Device Authentication rolls out gradually to all OAuth2 flows. A 6-digit verification code replaces the clickable SMS link across all partner integrations, matching the approach already live on Swan's web banking. This closes a remaining authentication fraud vector for partners using their own client_id.
For your end users signing in or signing up from desktop:
\nFor identification, two text messages are sent: one with a redirection link, and one to trigger identification on mobile.
\nNo code changes are required, but please update your support documentation, guides, and flow screenshots accordingly.
\nโ ๏ธ On June 4, Swan renames Card-prefixed merchant types and mutations to OnlineCard equivalents for accepting online card payments. The deprecated names are removed on this date; update your queries and mutations before then.
This rename clarifies the distinction between online card acceptance and in-person card acceptance (terminals, Tap to Pay). It only affects partners accepting payments through merchant profiles. Card issuing is unchanged.
\nQueries:
\nCardMerchantPaymentMethod โ OnlineCardMerchantPaymentMethod. Affects all queries that resolve CardMerchantPaymentMethod from MerchantProfile.merchantPaymentMethods or MerchantPaymentMethod.CardTransaction โ OnlineCardTransaction. The PaymentProduct enum gains a new OnlineCard value.CardMerchantPayment โ OnlineCardMerchantPayment.Mutations and simulations:
\nrequestMerchantPaymentMethods now requires OnlineCard instead of Card.simulateMerchantPaymentMethodRequestOutcome now requires the OnlineCardMerchantPaymentMethod typename.simulateIncomingCardAuthorization โ simulateIncomingOnlineCardAuthorization.simulateIncomingCardBooking โ simulateIncomingOnlineCardBooking.๐ On May 21, 2026, public onboarding URLs will switch to the current onboarding API for all new onboardings. The previous public onboarding interface will be retired.
\nIf you use public onboarding URLs without any prefilling, no action is needed. If you prefill onboarding fields through the API before redirecting to the onboarding URL, refer to the migration guide or reach out to your Swan contact to plan your migration.
\nโ๏ธ Custom details for the Other purpose: when a supporting document with the purpose Other is requested, a new purposeDetails field on the SupportingDocumentPurpose object specifies what document is needed (for example, \"Company structure chart\"). Query purposeDetails under requiredSupportingDocumentPurposes and display the description to your account holders to guide their upload. See the supporting documents guide for details.
โฑ๏ธ On May 20, 2026, the consent notification endpoint timeout will be reduced from 3 seconds to 2 seconds. This change applies to consent flows (sensitive operations), not OAuth2 flows such as login or authentication. The shorter timeout gives Swan enough time to fall back to text message within the 3.5-second 3-D Secure (3DS) window.
\nIf your integration uses in-app consent notifications, make sure your endpoint responds within 2 seconds. Aim for 1.5 to 1.8 seconds to leave margin. If your response is slower, Swan falls back to text message. No action is required if you don't use in-app consent notifications.
\nโ ๏ธ On September 30, 2026, the previous onboarding API will be shut down and all previous endpoints will no longer be available. The current onboarding API has been generally available since March 2026. If you're still using the previous API, migrate before this date. Refer to the migration guide or reach out to your Swan contact to plan your transition.
", "url": "https://docs.swan.io/changelog/23-april-2026", "title": "23 April 2026", "summary": "New features", "date_modified": "2026-04-23T00:00:00.000Z", "tags": [] }, { "id": "https://docs.swan.io/changelog/9-april-2026", "content_html": "๐ Physical cards that haven't been activated after their estimated delivery date now trigger automatic reminder emails to cardholders. Reminders are sent at configurable intervals until the card is activated. Configure this from your Dashboard > Settings > Notifications.
\n๐งโ๐คโ๐ง Changing account administrator is now easier to handle for your customers. The dedicated request form determines which supporting documents are required based on company type and reason for change, so requesters upload the right documents on the first attempt. Share the guided form directly with your customers.
\n๐ซ Swan now requires email address verification when creating a new project in Sandbox. This limits impersonation risk and reinforces security across all projects.
\n๐ก๏ธ The Web Banking sign-up flow has been updated to strengthen protections against social engineering and fraud. Users now complete sign-up on desktop by entering a 6-digit SMS verification code and their personal information. They then switch to mobile to complete identification via a link sent to their device.
\n๐ On April 30, the deprecated InternalCreditTransfer value will be removed from the PaymentProduct enum. Remove any references to this value from your transaction queries and filtering before this date.
๐
You can now configure card spending limits with calendar-based periods, in addition to rolling periods. Calendar-based limits reset on a fixed schedule instead of a rolling window. This makes it easier for finance teams to align card budgets with their accounting periods. Configure calendar limits using the new mode field in SpendingLimitInput with options for daily, weekly, or monthly recurrence.
๐ผ๏ธ A new no-code onboarding interface is now in beta and available from your Dashboard. It delivers a cleaner and more consistent onboarding experience, improves data collection for better risk assessment and regulatory compliance, and removes the need to build and maintain the interface yourself. For a visual overview of the new onboarding flow, browse the Figma prototype.
\n๐งญ The data in your Dashboard Insights tab is updated for Overview, Credit Transfers, All Transactions, and Cards.
\nStarting April 2, churned account holder data in the Overview tab will also reflect the new account closure reasons.
\n๐ Starting April 2, Swan provides more granular closure reason codes to help you understand why an account was closed. The new reasons are visible via the API and on your Dashboard.
\nCloseAccountReasonType values will be replaced with more granular codes: PartnerReason, Inactivity, and CapitalDepositReason. These were previously used for account opening refusals, capital deposit cancellations, and account closures.๐ Starting April 2, CapitalDepositCaseCanceledStatusInfo gains a cancellation reason code when the case status is Canceled. You can also subscribe to the CapitalDepositCaseEvent.Canceled webhook to receive notifications when a capital deposit case is canceled.
Capital deposit cases canceled before April 2 have a null cancellation reason at the capital deposit level. For those cases, refer to the account-level deprecated closure reason CapitalDepositReason.
๐งญ The new Onboarding API is now live in beta. It improves data collection for better risk assessment and regulatory compliance, and delivers a cleaner developer experience with structured inputs, typed responses, and updated mutations and queries. Documentation is updated to reflect all new validations.
\n๐ CapitalDepositDocumentRefusedStatusInfo now includes an optional reason string field with a free-text explanation of why a document was refused. You can view the exact explanation on your Dashboard, alongside the existing reasonCode value.
๐ Account holders can now be filtered by their Know Your Customer (KYC) verification requirements, both in the Dashboard and through the API. Supported filters include FirstTransferRequired, SupportingDocumentsRequired, UboDetailsRequired, LegalRepresentativeDetailsRequired, OrganizationDetailsRequired, TaxIdRequired, and Other.
๐ Starting April 2, CapitalDepositCaseCanceledStatusInfo gains a cancellation reason code when the case status is Canceled. You can also subscribe to the CapitalDepositCaseEvent.Canceled webhook to receive notifications when a capital deposit case is canceled.
Capital deposit cases canceled before April 2 have a null cancellation reason at the capital deposit level; for those cases, refer to the account-level deprecated closure reason CapitalDepositReason.
โ ๏ธ Starting April 2, three CloseAccountReasonType values are replaced with more granular codes. The deprecated values are PartnerReason, Inactivity, and CapitalDepositReason, previously used for account opening refusals, capital deposit cancellations, and account closures.
Accounts closed before April 2 keep their original reason codes. Refer to the deprecated reason codes for the full mapping.
\n๐ฉ Our new white-labelled email notifications are now live in Production Live. If you have automations in place, check your KYC operations now in Production Sandbox. Affected notifications:
\n๐๏ธ In April, weโre rolling out a new whiteโlabelled portal for periodic KYC reviews (โreโKYCโ). It lets account admins confirm or update customer details in a multilingual interface, with pre-filled information and automated email reminders.
\n๐ป A new desktop sign-up flow for Web Banking is coming soon. Authentication and personal information will be completed on desktop: users receive a 6-digit verification code by SMS, enter the code, create a passcode, then enter personal information before switching to mobile to complete identification. This keeps authentication on a single device, reducing exposure to phishing and social engineering attacks. No changes are required on your side.
", "url": "https://docs.swan.io/changelog/12-march-2026", "title": "12 March 2026", "summary": "New features", "date_modified": "2026-03-12T00:00:00.000Z", "tags": [] }, { "id": "https://docs.swan.io/changelog/26-february-2026", "content_html": "๐ฉ Following the December 18 postponement, the new white-labelled email notifications will be activated in Production Live starting March 12.\nThey're now available for testing in Production Sandbox, so you can assess the impact on your KYC operations if you have automations in place.
\nOur new white-labelled email notifications:
\n๐ The sign-in flow for Web Banking on desktop was updated on February 18.\nUsers now receive a 6-digit verification code by SMS, and enter both the code and their passcode on desktop, instead of clicking a link and entering their passcode on mobile.\nThis update improves security by making it harder for unauthorized users to access accounts.
\n๐ We've added idempotency to several mutations, so you can more safely accept payments and fund accounts without risking duplicates:
\ninitiateMerchantPaymentCollection for Internal Direct Debit.initiateSepaDirectDebitMerchantPayment for incoming SEPA Direct Debit.initiateFundingRequest for account funding.โ ๏ธ Starting April 2, the following CloseAccountReasonType values will be deprecated to provide more granular reason codes for account opening refusals, capital deposit cancellations, and account closures:
PartnerReason: use RequestedByHolder instead.Inactivity: use DormantAccount instead.CapitalDepositReason: use any of the new specific reason codes instead.๐ On March 31, accountId becomes mandatory in internationalBeneficiaryDynamicForms and internationalCreditTransferTransactionDetailsDynamicForm. It's available now as optional; update your integration before this date.
๐ On April 1, the following fields will be removed from accountStatement, Account.statements, and generateAccountStatement:
fees: replaced by feeCredits and feeDebits.status: replaced by statusInfo.url in type: moved to statusInfo.๐ Starting February 26, B2B received direct debit mandates will return to ConsentInitiationPending status instead of Canceled when consent is refused or expires. This will allow end users to retry activating the mandate using the enableReceivedDirectDebitMandate mutation.
๐ Swan is regenerating all bank details PDFs created before November 4, 2025, to reflect Swan SAS's new address. Bank details generated after this date already contain the new address.
\nThis applies to both main and virtual IBANs. Subscribe to the Account.Updated webhook to synchronize your system. This webhook is triggered only when main IBAN bank details are regenerated. Query your virtual IBANs separately to synchronize them as well.
The process happens in two stages:
\n๐งญ SEPA Credit Transfers received without a customer-provided reference now display as empty strings in Web Banking and the API, instead of showing NotProvided.
๐ Identify which user initiated a credit transfer by querying the payment before consent is granted, or by storing user details at the time of initiation.
\n๐ง The reference field for standing orders has been updated to align with SEPA scheme requirements: the underscore character (_) is no longer accepted. New regex pattern: ^[A-Za-z0-9-?.+\\/:,'() ]{1,35}$.
๐ฎ Starting February 5, new rejections apply to the openAccount mutation to prevent fraud patterns involving successive opening and closing of multiple accounts to bypass the account creation limit:
Opened, Suspended, Closing, or Closed). Previously, only Opened accounts counted. This change affects the existing AccountHolderAccountsCreationLimitRejection.Suspended, Swan rejects opening multiple accounts with AccountHolderAccountsSuspendedStatusNotEligibleRejection.๐ซ Starting February 26, the following rules apply to limited accounts:
\nThis change mainly affects the first incoming transfer made while the account holder is still completing verification. During verification, the account remains limited, and any transfer exceeding these limits is automatically rejected.
\nCapital deposit accounts are unaffected, except that all transfers sent on SWIFT are now rejected for these accounts as well.
", "url": "https://docs.swan.io/changelog/29-january-2026", "title": "29 January 2026", "summary": "Important update", "date_modified": "2026-01-29T00:00:00.000Z", "tags": [] } ] }