๐
Set card spending limits based on calendar periods (resetting monthly on the 1st, weekly on Monday, or daily at midnight) instead of rolling periods. Calendar-based limits make it easier for finance teams to control budgets by calendar month, week, or day. Configure calendar limits using the new mode field in SpendingLimitInput with options for daily, weekly, or monthly calendar recurrence.
๐ Subscribe to email notifications directly from the Changelog to stay informed about API updates and breaking changes.
\n๐ The generateTransactionStatement mutation now works for incoming and outgoing Booked International Credit Transfers. Use it to prove a transaction was executed by Swan.
๐ Starting January 19, a new accountId field is available as an optional parameter in internationalBeneficiaryDynamicForms. It becomes mandatory on March 31, 2026. Update your integration during this period to ensure continued support for international credit transfer queries.
๐ On April 1, 2026, 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.url, previously in the type object, will only be available in statusInfo.๐งญ 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.
\n๐ The Insights tab on your Dashboard now includes new visualizations:
\n๐ฉ 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.
\nWe 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.
\nAffected notifications:
\n๐ค 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.
\n๐ 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):
\nYour 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.
\n๐ The Insights tab on your Dashboard now includes new visualizations:
\nComing soon: Support operations graphs.
\n๐ก๏ธ 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.
", "url": "https://docs.swan.io/changelog/4-december-2025", "title": "4 December 2025", "summary": "New features", "date_modified": "2025-12-04T00:00:00.000Z", "tags": [] }, { "id": "https://docs.swan.io/changelog/6-november-2025", "content_html": "โ
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.
๐ Starting December 1, Swan Support will no longer manually register SEPA Direct Debit B2B mandates. You can now:
\n๐งน 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.
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.
\n๐ 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:
WaitingForInitialRequirements, PendingInternalReview, or WaitingForAdditionalInformation. Also supports the deprecated WaitingForRequirements status.PendingOnboarding, WaitingForVerification, or WaitingForTransfer.Updating an amount automatically recalculates the total capital deposit.
\n๐ฌ 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:
WaitingForInitialRequirements, PendingInternalReview, or WaitingForAdditionalInformation. Also supports the deprecated WaitingForRequirements status.Finalized.Updates sync automatically across both the capital deposit case and the associated account holder.
\n๐ Account statements now feature a more refined structure, clearer field names, and precise status tracking.
\nVoided 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.fees field is now split into feeCredits (sum of credit fee transactions) and feeDebits (sum of debit fee transactions).type field is now renamed to format.AccountStatement.Voided now triggers when a statement is marked asVoided.๐งน 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.url, previously in the type object, is now only in statusInfo.๐ญ To improve data quality for physical card orders, we now use a regex to enforce better formatting of the postalCode field in physical addresses.
๐ Starting November 12:
\nonboarding(id: ID!) query may return null when no onboarding exists for the given ID, instead of always returning an Onboarding object.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:
save parameter now defaults to false.mode parameter is now a required field. The default value is set to Regular.isMyOwnIban and beneficiaryId input fields have been removed.ValidationRejection error instead of ForbiddenRejection when an input contains invalid data.โ๏ธ 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.
๐ฆ With Multiple Accounts, company account holders can create additional accounts without repeating onboarding or Know Your Business (KYB) processes.
\n๐ 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.
โ ๏ธ The following updates are currently available in our Sandbox environment and will be released to the Live environment on October 9.
\ninitiateCreditTransfers endpoint updatesโbeneficiaryVerificationToken in the initiateCreditTransfers call.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.beneficiaryVerificationResults field has been added to InitiateCreditTransfersSuccessPayload.scheduleStandingOrder endpoint updatesโscheduleStandingOrder mutation, we'll automatically verify the beneficiary's details and display the results in the consent screen.beneficiaryVerificationResult field has been added to the ScheduleStandingOrderSuccessPayload.๐ You can now retrieve the beneficiaryVerificationResult using the transaction, transactions, standingOrder, and TrustedBeneficiary queries.
๐ฅ 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.
\n๐ 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.
๐ 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 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.
๐ก 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:
\nWaitingForInformation 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.supportingDocumentCollections field will also be available at the merchant profile level for providing required documents.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.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:
save parameter will default to false.mode parameter will be a required field. The default value is set to Regular.isMyOwnIban and beneficiaryId input fields will be removed.ValidationRejection error instead of ForbiddenRejection when an input contains invalid data.๐งญ Starting October 21, card-issuing spending limits will be aggregated at the hour level.\nTo calculate card spending limits, each payment is recorded at the start of the hour. The rolling period resets every hour.\nThis change applies to cards with daily, weekly, and monthly spending limit periods.
๐ 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.
\nโน๏ธ You can now cancel merchant SEPA Direct Debit payments using the cancelMerchantPayment mutation.\nRefer 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.
๐ Starting October 1, we're removing the paymentId field from the initiateSepaDirectDebitMerchantPayment mutation.\nInstead, retrieve the ID from the merchantPayment field, which now returns the Merchant Payment object.\nWe'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.\nFor example, Spanish residents opening French accounts will need to provide their tax identification number.