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.

New features​

💳 Payment Control now supports €0 authorizations and credit authorizations, identifiable with TransactionSide! as Credit. Activate this feature from your Dashboard > Developers > Payment control.

🔑 Idempotency is now available for initiateCreditTransfers. Add an idempotency key to your transfer queries to improve reliability and prevent duplicate transactions.

📥 You can now export transaction data in .csv format from your Dashboard or with the API by calling the exportTransactionData mutation.

Improvements​

🧑‍🤝‍🧑 Server-to-server consent is now available for all account membership mutations, enabling you to reduce manual operations and scale more easily.

🔢 A new Service section is now available in your Dashboard > Insights. This section provides essential data on your KYC and Transaction Monitoring operations, including processing volumes and SLA performance. Related metrics have been moved from the Onboarding section to centralize this information.

New features​

📖 Learn about the new Verification of Payee regulation, its impact on your users, and how you can update your Swan integration to improve your payment experience.

Improvements​

👥 Get more balance information for booked transactions using BookedTransactionStatusInfo.balanceAfter. This object provides:

• amount - replaces the existing BookedBalanceAfter.amount (see upcoming breaking changes).
• sequenceNumber - new account-level transaction counter for new transactions (historical transactions show null).

🧭 Customize column width on all Dashboard pages to make the data easier to read.

🪝 Two new webhooks are now available to update you on rolling reserve changes. TransactionRollingReserve.Updated is triggered when the release date is changed, and TransactionRollingReserve.Released will indicate that the reserved funds are now available.

API updates​

Upcoming breaking changes​

📄 Starting August 28, we'll start using these new, already available enum variables: USPersonStatusDeclaration and ProofOfBusinessActivity for SupportingDocumentPurpose, and W9, W8, and CertificateOfLossOfNationality for SupportingDocumentType.

👥 Starting December 31, the bookedBalanceAfter field will be removed from the transaction query. Please use the balanceAfter.amount on BookedTransactionStatusInfo.

New features​

🔗 Send a SEPA Direct Debit B2B mandate registration link to users with the canInitiatePayments permission. Get the link from your Dashboard > Data > Accounts page.

Improvements​

💳 One-off single use virtual cards now default to expiring 30 days after creation. This applies when SpendingLimitPeriod is set to Always in the addSingleUseVirtualCard and addSingleUseVirtualCards mutations. You can change this by setting a custom cardContractExpiryDate.

🧭 Transaction confirmation documents now follow a new, more readable naming convention that includes the document language. The new format is: TransactionConfirmation_[transactionId]_[documentLanguage].

Updates​

🪪 Starting August 7, we'll recommend QES as the identification method for German accounts, replacing the current Expert level. If you use Auto, no action is needed. This change will apply automatically.

API updates​

Upcoming breaking changes​

🛑 Starting August 18, the initiateCheckMerchantPayment mutation will return a new rejection: MerchantPaymentAlreadyExistsRejection. This occurs when you try to create a merchant payment, but the CMC7 value is already used by an existing payment that hasn't been Rejected or Canceled. If the existing payment with the same CMC7 was Rejected or Canceled, your mutation will still succeed.

💳 Starting August 21, refund transactions will be linked to the paymentId of their original debit authorization when referenced by merchants. This change affects you only if you expect debit clearing transactions on a debit authorization.

API updates​

Upcoming breaking changes​

🔐 Starting July 10, failed consent attempts will trigger the Consent.Failed webhook. Previously, failed consents triggered Consent.Granted, due to a bug. The new webhook is already available in your Dashboard.

✉️ Starting July 21, the shippingProvider field in PhysicalCardToActivateStatusInfo and PhysicalCardRenewedStatusInfo will be migrated from a String to an ENUM. On the same day, the shipping provider values La Poste and CORREOS will be removed.