Important update​

📎 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.

This 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:

• Starting Friday, January 30, regeneration begins in Production Sandbox.
• Starting Monday, February 2, regeneration begins in Production Live, pending successful completion of Production Sandbox. It should take one week to complete.

Improvements​

🧭 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.

🔧 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}$.

API updates​

Upcoming breaking changes​

👮 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:

• All accounts now count toward the maximum limit regardless of status (Opened, Suspended, Closing, or Closed). Previously, only Opened accounts counted. This change affects the existing AccountHolderAccountsCreationLimitRejection.
• If one or more of the account holder's accounts is Suspended, Swan rejects opening multiple accounts with AccountHolderAccountsSuspendedStatusNotEligibleRejection.

🚫 Starting February 26, the following rules apply to limited accounts:

• Incoming SEPA Credit Transfers (instant or regular) exceeding €50 are automatically rejected.
• The maximum cumulative balance is €150.
• Any incoming SEPA Credit Transfer, regardless of amount, that would cause the balance to exceed this limit is also rejected.
• Any incoming SWIFT transfer, regardless of amount, is automatically rejected.

This 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.

Capital deposit accounts are unaffected, except that all transfers sent on SWIFT are now rejected for these accounts as well.

New features​

📖 You can now subscribe to email notifications directly from the Changelog. Subscribe to receive regular updates about new features, API improvements, and upcoming breaking changes.

Improvements​

📄 The generateTransactionStatement mutation now works for incoming and outgoing Booked International Credit Transfers. Use it to prove a transaction was executed by Swan.

API updates​

Upcoming breaking changes​

🌍 Starting January 19, a new accountId field is available as an optional parameter in internationalBeneficiaryDynamicForms and internationalCreditTransferTransactionDetailsDynamicForm. This field becomes mandatory on March 31, 2026. Update your integration before this date to ensure continued support for international credit transfer queries.

Reminders​

📆 On April 1, the following fields will be removed from the accountStatement and Account.statements queries and from the generateAccountStatement mutation response:

• fees will be replaced by feeCredits and feeDebits.
• status will be replaced by the statusInfo object.
• The statement download url, previously in the type object, will only be available in statusInfo.

New features​

🧭 We're releasing a preview of the documentation for our new onboarding API. Built to strengthen risk assessment and regulatory compliance through improved data collection, it also delivers a better developer experience with cleaner mutations and queries, structured inputs, and typed responses. Full launch is planned for Q1 2026.

Improvements​

📈 The Insights tab on your Dashboard now includes new visualizations:

• Capital deposits: New data improving visibility on iteration time for internal reviews.
• Support: New dedicated section tracking support tickets, categorization, and SLAs.

Important update​

📩 Following an incident during activation of the new white-labelled email notifications announced on December 4, we rolled back to the previous account opening notifications within an hour. The December 18 breaking change for account membership invitations is also postponed.

We plan to activate all new white-labelled notifications in January 2026 with two weeks' notice. You'll be able to test them in Production Sandbox beforehand.

Affected notifications:

• Your account terms and conditions.
• First transfer.
• Request supporting documents.
• Request supporting documents reminders.
• Your account is opened.
• Join your banking space.

New features​

🤖 Swan's new MCP (Model Context Protocol) servers give AI assistants direct access to Swan's GraphQL schema and documentation. Use them with Claude Desktop, Claude Code, or Cursor to generate accurate queries and get answers about the API.

Improvements​

🔗 Your users can now upload merchant profile supporting documents directly in Web Banking. Retrieve the upload link from supportingDocumentCollectionUrl in the SupportingDocumentCollection object and share it with them.

📩 Account opening email notifications have been rebranded to support your project's branding (logo, accent colors):

• Account onboarding: Your account terms and conditions.
• Account holder verification: First transfer, Request supporting documents, Request supporting documents reminders, Your account is opened.

Your current configuration has been applied automatically to avoid disruptions. Swan can configure some of these notifications on your behalf; submit a request if you're interested.

📈 The Insights tab on your Dashboard now includes new visualizations:

• Capital deposits: New section tracking deposit status, total lead time, and step duration.
• KYC multi-touch lead time: New graph tracking total verification time for complex cases. The "One-touch vs. multi-touch" graph now focuses on completed processes, with iterations simplified to match service level agreements ("Within 9 hours" vs. "More than 9 hours").

Coming soon: Support operations graphs.

API updates​

Upcoming breaking changes​

🛡️ Starting December 18, we're introducing stricter input validation for several mutations to improve security and error handling. The following fields now enforce specific formats, returning a ValidationRejection for invalid values:

Mutation	Field	Required format
addVirtualIbanEntry	accountId	Valid UUID
disableAccountMembership	accountMembershipId	Valid UUID
resumeAccountMembership	accountMembershipId	Valid UUID
resumeAccountMembership	consentRedirectUrl	Valid URL

📩 Starting December 18, the account membership invitation notification will be rebranded with your project's branding (logo, accent colors). If you use a forked version of Web Banking, fetch and deploy the latest version from Swan's repository to continue receiving Swan-sent invitation emails.

Improvements​

✅ The beneficiary name field in the verifyBeneficiary mutation now enforces a maximum length of 70 characters for SEPA beneficiaries and Swan accounts. This matches the maximum length supported for SEPA Credit Transfer initiations, preventing rejections during the payment flow.

💳 Recurring SingleUseVirtualCard instances now remain active when their cardholder's account membership is disabled. When that happens, the card automatically reassigns to the account's legal representative, ensuring uninterrupted recurring expenses.

Updates​

📝 Starting December 1, Swan Support will no longer manually register SEPA Direct Debit B2B mandates. You can now:

• Share a SEPA Direct Debit B2B mandate registration link directly with your users.
• Embed the registration link in your application.
• Use Swan's API to manage mandate registration programmatically.

API updates​

Upcoming breaking changes​

🧹 Starting December 1, the deprecated companyInfoBySiren query will be removed. Company information can now be retrieved directly during onboarding creation and updates, eliminating the need for separate queries.

🧹 On February 5, 2026, the deprecated status field will be removed from the CapitalDepositCase object. Migrate to the statusInfo field, which was introduced on October 23. This provides more granular status updates, including WaitingForInitialRequirements, PendingInternalReview, and WaitingForAdditionalInformation.

Improvements​

We've made improvements to capital deposits to give you better visibility into case progress and more flexibility to correct information without restarting the process.

🔍 We improved granular status tracking for capital deposit cases by introducing the statusInfo field in the CapitalDepositCase object. This field provides more detailed status updates and replaces the generic WaitingForRequirements status with three clear stages:

• WaitingForInitialRequirements: Shareholder verification, fund transfers, document uploads, and company onboarding are pending.
• PendingInternalReview: Swan is reviewing submitted information and documents.
• WaitingForAdditionalInformation: Swan has requested corrections or additional details.

The existing status field remains available but is deprecated. We recommend migrating to statusInfo for more detailed status information, though you can adopt it at your own pace without breaking your integration. The Dashboard continues to display the status label.

💰 You can now correct shareholder deposit amounts with the updateCapitalDepositShareholderAmount mutation. Requirements:

• Capital deposit case status is WaitingForInitialRequirements, PendingInternalReview, or WaitingForAdditionalInformation. Also supports the deprecated WaitingForRequirements status.
• Shareholder status is PendingOnboarding, WaitingForVerification, or WaitingForTransfer.

Updating an amount automatically recalculates the total capital deposit.

🏬 You can now correct company details linked to capital deposits with the updateCapitalDepositCompany mutation. This lets you update the company name and postal address. Requirements:

• Capital deposit case status is WaitingForInitialRequirements, PendingInternalReview, or WaitingForAdditionalInformation. Also supports the deprecated WaitingForRequirements status.
• Company onboarding is Finalized.

Updates sync automatically across both the capital deposit case and the associated account holder.

📄 Account statements now feature a more refined structure, clearer field names, and precise status tracking.

• New Voided status: We've added the Voided status to mark incorrect statements. When a statement is voided, a corrected version automatically regenerates with identical characteristics (format, language, dates). The statusInfo object reflects this new status.
• Refined fee fields: The fees field is now split into feeCredits (sum of credit fee transactions) and feeDebits (sum of debit fee transactions).
• Clearer format naming: The type field is now renamed to format.
• New webhook: AccountStatement.Voided now triggers when a statement is marked asVoided.

API updates​

Upcoming breaking changes​

🧹 On December 1, the deprecated totalCapitalDepositAmount field will be removed from the CreateCapitalDepositCaseInput object. Instead, specify each shareholder's deposit amount in the individualShareholders and companyShareholders arrays. Swan automatically calculates the total. The calculated total remains available in the CapitalDepositCase response.

⚠️ Starting January 23, 2026, the following fields will be removed from the accountStatement and accountStatements queries and from the generateAccountStatement mutation response:

• fees is replaced by feeCredits and feeDebits.
• status is replaced by the statusInfo object.
• The statement download url, previously in the type object, is now only in statusInfo.

Improvements​

📭 To improve data quality for physical card orders, we now use a regex to enforce better formatting of the postalCode field in physical addresses.

API updates​

Upcoming breaking changes​

🔍 Starting November 12:

• The onboarding(id: ID!) query may return null when no onboarding exists for the given ID, instead of always returning an Onboarding object.
• The following deprecated fields will be removed:
  • verificationFlow from the OnboardingInfo object.
  • redirectUrl from both the Onboarding and OnboardingInfo objects. It has been replaced by the oauthRedirectParameters object.
  • title from the Ultimate Beneficial Owner (UBO) object. It has been replaced by the gender field.
  • onboardingState from the OnboardingInfo object.

💸 On October 19, we will introduce the following updates to the initiateCreditTransfers endpoint to improve its usability and clarity:

• The save parameter now defaults to false.
• The mode parameter is now a required field. The default value is set to Regular.
• The isMyOwnIban and beneficiaryId input fields have been removed.
• The API now returns a ValidationRejection error instead of ForbiddenRejection when an input contains invalid data.

Updates​

⚖️ Starting October 31, the taxIdentificationNumber will be a mandatory field at onboarding when an account holder's residency country does not match the accountCountry. This is to comply with CRS (Common Reporting Standard) regulations.

New features​

🏦 With Multiple Accounts, company account holders can create additional accounts without repeating onboarding or Know Your Business (KYB) processes.

Improvements​

🚚 We've added LaPosteTracked as a new shipping method for international card deliveries. This gives cardholders outside of France a reliable way to track their card's delivery from our printing hub.

📄 We've made it easier to reconcile payments by allowing you to use structured and unstructured formats for invoice references in transactions. For SEPA Credit Transfers, use the labelType field to choose the reference standard and the label field for the value. When you retrieve transaction data, this value will be in the transaction.label. You can also specify the ogmVcs type for Belgian OGM VCS references.

Verification of Payee (VoP) updates​

⚠️ The following updates are currently available in our Sandbox environment and will be released to the Live environment on October 9.

💸 initiateCreditTransfers endpoint updates​

• We'll automatically verify the beneficiary's details and display the results on the consent screen for single SEPA Credit Transfers without a beneficiaryVerificationToken in the initiateCreditTransfers call.
• You can now include a beneficiaryVerificationToken when initiating a credit transfer instead of providing full beneficiary details. Account membership rights remain the same as those described in beneficiaries permissions when using tokens.
• A new beneficiaryVerificationResults field has been added to InitiateCreditTransfersSuccessPayload.

📅 scheduleStandingOrder endpoint updates​

• When calling the scheduleStandingOrder mutation, we'll automatically verify the beneficiary's details and display the results in the consent screen.
• A new beneficiaryVerificationResult field has been added to the ScheduleStandingOrderSuccessPayload.

📒 You can now retrieve the beneficiaryVerificationResult using the transaction, transactions, standingOrder, and TrustedBeneficiary queries.

VoP rollout​

📥 Starting October 5, we'll automatically handle all incoming VoP requests from other Payment Service Providers (PSPs). Beneficiary details will be verified, and the result will be returned to the PSP before funds are transferred into a Swan account. No action is required from you.

🃏 On October 9, company accounts will be opted out of VoP for bulk credit transfers by default, while individual accounts will be opted in. You can change the setting for bulk transfers with the updateAccountSettings mutation, once the verifyBeneficiary mutation is implemented.

📡 On October 9, the verifyBeneficiary mutation will be available to verify beneficiary details before initiating credit transfers. Use the save parameter to add a trusted beneficiary when the returned token successfully initiates the credit transfer.

📩 On October 19, the save parameter of the verifyBeneficiary mutation will default to false.

Upcoming breaking changes​

🛑 Starting October 9, the initiateCreditTransfers mutation will return a new rejection reason if the BeneficiaryVerificationToken was already used to initiate another credit transfer.

✔️ Starting October 31, the beneficiaryVerification query will be deprecated. Use the verifyBeneficiary mutation instead to ensure uninterrupted service.

Improvements​

🛒 Improvements to merchant profiles and merchant payment methods, and the requestMerchantProfile and requestMerchantProfileUpdate mutations:

• The Testing APIs simulateMerchantProfileRequestOutcome and simulateMerchantPaymentMethodRequestOutcome mutations now support the new WaitingForInformation status and return a list of verificationRequirements.

• A new optional field expectedMerchantProfileAdditionalInformation is now available at the projectInfo level. This field allows you to customize information collected for merchant profiles when configured as part of your merchant feature approval process.

  The information can then be provided using the additionalInformation field in merchant profiles and in the requestMerchantProfile and requestMerchantProfileUpdate mutations.

• The invoiceExample field has been deprecated.

• The expectedMonthlyPaymentVolume, merchantWebsite, socialNetwork, supportWebsite, and termsAndConditions fields are being deprecated.

• We've deprecated the rejectReasons field and replaced it with rejectionReasons.

API updates​

Upcoming breaking changes​

📡 Starting October 9, bulk SEPA Credit Transfers from individual account holders will be rejected if verification tokens aren't included in the payment initiation. You must either implement the verifyBeneficiary mutation (recommended) or restrict bulk credit transfer access to company accounts only. This change applies to both Live and Sandbox environments.

💳 On October 16, the CardUrl field will be removed. Use cardMaskedNumber, expiryDate, and cardDesignUrl instead.

🛒 On October 16, the following merchant onboarding and payment methods breaking changes will take effect:

• A new WaitingForInformation status and verificationRequirements list will be available to show missing information on merchant profiles and payment methods. Submit the required information using the requestMerchantProfile or requestMerchantProfileUpdate mutations.
• A new supportingDocumentCollections field will also be available at the merchant profile level for providing required documents.
• The invoiceExample, expectedMonthlyPaymentVolume, merchantWebsite, socialNetwork, supportWebsite, termsAndConditions will be removed. Use expectedMonthlyMerchantProcessingVolume, merchantWebsiteUrl, socialNetworkUrl, supportWebsiteUrl, and termsAndConditionsUrl instead.
• rejectReasons will be removed for card payment methods.
• rejectionReasons for Rejected merchant profiles and merchant payment methods will become mandatory in Testing APIs simulateMerchantProfileRequestOutcome and simulateMerchantPaymentMethodRequestOutcome.
• Dynamic rolling reserve changes and maximum payment amount limits will be introduced at the merchant payment method level to mitigate risk. Subscribe to the MerchantPaymentMethod.Created and MerchantPaymentMethod.Updated webhooks for these updates.

💸 Effective October 19, we're introducing updates to the initiateCreditTransfers endpoint to improve its usability and clarity:

• The save parameter will default to false.
• The mode parameter will be a required field. The default value is set to Regular.
• The isMyOwnIban and beneficiaryId input fields will be removed.
• The API will return a ValidationRejection error instead of ForbiddenRejection when an input contains invalid data.

Update​

🧭 Starting October 21, card-issuing spending limits will be aggregated at the hour level. To calculate card spending limits, each payment is recorded at the start of the hour. The rolling period resets every hour. This change applies to cards with daily, weekly, and monthly spending limit periods.

New features​

📖 Get a head start on what's next. We've added a Preview section to our documentation, giving you early access to our features. Use these previews to plan your future roadmap. Note that functionality may change before the official release.

Improvements​

⏹️ You can now cancel merchant SEPA Direct Debit payments using the cancelMerchantPayment mutation. Refer to the availableToCancel balance to check if a specific payment can be canceled.

🔍 Use the isCancelable field to verify whether scheduled account funding transactions are eligible for cancellation.

API updates​

Upcoming breaking changes​

🔄 Starting October 1, we're removing the paymentId field from the initiateSepaDirectDebitMerchantPayment mutation. Instead, retrieve the ID from the merchantPayment field, which now returns the Merchant Payment object. We're also deprecating the paymentId field.

⚖️ Starting October 31, the taxIdentificationNumber will be a mandatory field at onboarding when an account holder's residency country does not match the accountCountry. This is to comply with CRS (Common Reporting Standard) regulations. For example, Spanish residents opening French accounts will need to provide their tax identification number.