Changelog

Below is a log of changes to the Connect Financial API. Updates that affect only products or features in beta or limited release may not be reflected.

Each change can be described as either a breaking change or an ongoing change.

Ongoing changes: Ongoing changes are backwards-compatible and are added on an ongoing basis. These updates improve functionality without requiring changes to your existing integration.

Breaking changes: When we make backwards-incompatible changes, these are marked in the changelog with the 💥 symbol. Breaking changes may require you to update your integration to continue working properly.

Prior to the production release of breaking changes, we do two things:

We release documentation for breaking changes in advance to give customers time to adopt the new changes.
We make breaking changes available on our sandbox environment first. This allows you to explore the new changes and simplifies development.

Change Key

🌱 New feature

🍃 Improvement

🔧 Fix

💥 Breaking change

🔒 Security-related

Changelog

July 3rd, 2025

🌱 Added an endpoint for retrieving balance for a wallet, under GET wallets/:id/balance. For more information, see Get Wallet Balance.

🌱 Added an endpoint for retrieving transactions under /baas/transactions, which allows for filtering by user, wallet and portfolio ID - as well as other commonly used filters. For more information, see Search Transactions.

🌱 Added a set of endpoints for configuring webhook subscriptions. These allow you to add, retrieve and update webhook subscriptions. We will add more functionality to these over time. For more information, see Webhooks.

🍃 Added multiple QOL improvements across existing endpoints. These include improved response payloads, more descriptive HTTP error codes, as well as improved API docs.

🍃 Improved error message when attempting to create a customer with a duplicate email address.

🔧 Fixed issue where API requests triggered through the documentation interface were failing while working correctly when called externally.

August 11th, 2025

🔧 Minor fixes regarding list customer endpoint filters.

🍃 Improving dtos for wallet and card endpoints.

🍃 Configuring withdrawal endpoint to work with USD_TEST on sandbox.

🍃 Including LOCAL_US_WIRE withrawal option.

September 24th, 2025

🍃 Removed "Other" as option for individual customer enum.

🍃 Simplified inputs for the POST baas/transactions/withdrawal endpoint and improved its documentation.

🍃 Reduced the granularity of the individual customer occupation enum, accounting for just it's the macro categories (2 digits) instead of occupation (6 digits)

October 22nd, 2025

💥 Included a "v1" versioning prefix for endpoints

🌱 Added the KYC endpoints, for managing some required validations for the customer's onboarding. For more information see Compliance or contact your customer success maanger

🌱 Added the digital asset enpoints, for managing digital asset addresses and withdrawals. For more information see Digital Assets

November 13th, 2025

🍃 Simplified inputs for the POST v1/digital/withdrawal endpoint and improved its documentation.

🍃 Included "createdAt"property on transaction detailting and listing endpoints: GET /v1/baas/transactions/:id and GET /v1/baas/transactions

🍃 Occupation Field Made Optional for endpoints POST v1/customers and PATCH v1/customers/:customerId

🌱 Added the trade endpoints: GET /v1/trades/asset-pairs to list possible trades, POST /v1/trades/quotes to generate a executable trade and POST /v1/trades/quotes/:quoteId/execute to execute the quote, for more information see Trades

🔧 Fixed a bug related to address updating that was preventing KYC's from being initialized

November 19th, 2025

🌱 Added an endpoint for generating JWT tokens for Vault SDK integration, under POST /v1/vault/token. For more information, see Vault SDK.

December 3rd, 2025

🌱 Added an endpoint for retrieving VGS SDK configuration, under GET /v1/vault/config. This endpoint returns the vault ID, environment, CNAME, and route ID needed to initialize the Secure Connect SDK. For more information, see Vault SDK.

December 6th, 2025

🌱 Added bank lookup validation endpoints for validating routing numbers, SWIFT codes, and IBANs:

GET /v1/payments/validate/routing/:routingNumber - Validate a US ABA routing number and retrieve bank information
GET /v1/payments/validate/swift/:swiftCode - Validate a SWIFT/BIC code and retrieve bank information
GET /v1/payments/validate/iban/:iban - Validate an IBAN and retrieve bank/country information

🍃 Enhanced withdrawal endpoint (POST /v1/baas/transactions/withdrawal) with automatic bank validation:

Routing numbers are now validated for ACH and US_WIRE payments
SWIFT codes are validated when account number type is SWIFT
IBANs are validated when account number type is IBAN
Bank name and address are auto-populated from validation results if not provided

🍃 Enhanced counterparty endpoints with automatic bank validation:

POST /v1/customers/:customerId/portfolios/:portfolioId/counterparties now validates bank identifiers
PATCH /v1/customers/:customerId/portfolios/:portfolioId/counterparties/:counterpartyId now validates bank identifiers
Validated bank information (bankName, bankCity, bankState, bankCountry) is stored with counterparty records
Counterparty response DTOs now include bank validation information

December 8th, 2025

💥 Breaking Change: Simplified withdrawal endpoint DTO structure (POST /v1/baas/transactions/withdrawal)

The withdrawal endpoint has been updated to use a flat DTO structure, replacing the previous nested destination object. This change aligns the B2B gateway-api with the mobile-gateway-api pattern for consistency.

Key Changes:

Old Field (Nested)	New Field (Flat)	Notes
`destination.name`	`name`	Beneficiary name moved to root level
`destination.accountNumber.value`	`accountNumber`	Flattened, type assumed to be BBAN
`destination.accountNumber.type`	(removed)	Always BBAN
`destination.financialInstitutionId`	`routingNumber`	For ACH/US_WIRE domestic transfers
(new)	`bicSwiftCode`	For SWIFT/US_WIRE international transfers
`destination.personTypeCode`	`personTypeCode`	Uses Zenus enum (`P` for Private, `L` for Legal)
`destination.address.street1`	`street1`	Address fields moved to root level
`destination.address.street2`	`street2`	Optional
`destination.address.cityCounty`	`cityCounty`
`destination.address.stateRegion`	`stateRegion`
`destination.address.zip`	`zip`
`destination.address.countryCode`	`countryCode`
`destination.partyIdentification.identificationTypeCode`	`identificationTypeCode`	Optional
`destination.partyIdentification.identificationValue`	`identificationValue`	Optional
`preferredPaymentScheme`	`transferNetwork`	Renamed; see new enum values below
`details`	(removed)	No longer required

💥 Breaking Change: Updated transferNetwork enum values

The transferNetwork field now uses more specific values to distinguish between domestic and cross-border transfers:

Old Value	New Value(s)	Description
`ACH`	`ACH_DOMESTIC`	US domestic ACH transfer
`ACH`	`ACH_CROSSBORDER`	International ACH Transfer (IAT)
`US_WIRE`	`FEDWIRE_DOMESTIC`	Domestic Fedwire transfer using routing number
`US_WIRE`	`FEDWIRE_CROSSBORDER`	Cross-border Fedwire transfer using SWIFT code
`SWIFT`	`SWIFT`	International SWIFT transfer (unchanged)

Routing/SWIFT Code Requirements:

ACH_DOMESTIC: routingNumber is required, bicSwiftCode is not allowed
ACH_CROSSBORDER: routingNumber is required, bicSwiftCode is not allowed
FEDWIRE_DOMESTIC: routingNumber is required, bicSwiftCode is not allowed
FEDWIRE_CROSSBORDER: bicSwiftCode is required, routingNumber is not allowed
SWIFT: bicSwiftCode is required, routingNumber is not allowed

🍃 Enhancement: bankName and bankAddress are now optional

Both bankName and bankAddress fields are now optional. If not provided, they will be automatically populated from routing number or SWIFT code validation:

For routing number validation: Bank name and address retrieved from Federal Reserve Bank database
For SWIFT code validation: Bank name and address retrieved from SWIFT directory

This allows clients to omit these fields and rely on our validated bank data for accuracy.

Migration Example:

Old format:

{
  "walletId": "wallet_123",
  "amount": "100.00",
  "details": "Payment for services",
  "preferredPaymentScheme": "LOCAL_US_ACH",
  "destination": {
    "name": "John Doe",
    "accountNumber": { "value": "123456789", "type": "BBAN" },
    "financialInstitutionId": "021000021",
    "personTypeCode": "PRIVATE",
    "address": {
      "street1": "123 Main St",
      "cityCounty": "New York",
      "stateRegion": "NY",
      "zip": "10001",
      "countryCode": "US"
    }
  }
}

New format (with optional bankName/bankAddress omitted - will be auto-populated):

{
  "walletId": "wallet_123",
  "amount": "100.00",
  "name": "John Doe",
  "transferNetwork": "ACH_DOMESTIC",
  "personTypeCode": "P",
  "routingNumber": "021000021",
  "accountNumber": "123456789",
  "street1": "123 Main St",
  "cityCounty": "New York",
  "stateRegion": "NY",
  "countryCode": "US",
  "zip": "10001"
}

New format (with bankName/bankAddress provided - will use provided values):

{
  "walletId": "wallet_123",
  "amount": "100.00",
  "bankName": "Chase Bank",
  "bankAddress": "270 Park Ave, New York, NY 10017",
  "name": "John Doe",
  "transferNetwork": "ACH_DOMESTIC",
  "personTypeCode": "P",
  "routingNumber": "021000021",
  "accountNumber": "123456789",
  "street1": "123 Main St",
  "cityCounty": "New York",
  "stateRegion": "NY",
  "countryCode": "US",
  "zip": "10001"
}

Note on personTypeCode values:

P = Private (Individual)
L = Legal (Business)

💥 Breaking Change: Updated counterparty endpoints to use standardized transferNetwork enum

The counterparty endpoints now use the same BankPaymentSchemeEnum values as the withdrawal endpoint for consistency across all payment-related APIs.

Affected Endpoints:

POST /v1/customers/:customerId/portfolios/:portfolioId/counterparties - Create counterparty
PATCH /v1/customers/:customerId/portfolios/:portfolioId/counterparties/:counterpartyId - Update counterparty

Key Changes:

Old Field	New Field	Notes
`financialInstitutionId`	`routingNumber`	Renamed for clarity
(none)	`transferNetwork`	New required field - specifies payment network type
(none)	`bicSwiftCode`	New field for SWIFT transfers
(none)	`accountHolderName`	New required field for create operations
`accountNumberType`	(removed)	No longer required - Zenus treats all account numbers as BBAN

transferNetwork Enum Values:

ACH_DOMESTIC - US domestic ACH transfer
ACH_CROSSBORDER - International ACH Transfer (IAT)
FEDWIRE_DOMESTIC - Domestic Fedwire transfer
FEDWIRE_CROSSBORDER - Cross-border Fedwire transfer
SWIFT - International SWIFT transfer

Validation Rules by Transfer Network:

ACH_DOMESTIC / ACH_CROSSBORDER: routingNumber required
FEDWIRE_DOMESTIC: routingNumber required
FEDWIRE_CROSSBORDER / SWIFT: bicSwiftCode required

Create Counterparty Example:

Old format:

{
  "name": "John Doe",
  "financialInstitutionId": "063107513",
  "accountNumberType": "BBAN",
  "accountNumberValue": "123456789",
  "countryCode": "US",
  "street1": "123 Main St",
  "cityCounty": "Miami",
  "stateRegion": "FL",
  "zip": "33101"
}

New format:

{
  "transferNetwork": "ACH_DOMESTIC",
  "name": "John Doe",
  "accountHolderName": "John Doe",
  "routingNumber": "063107513",
  "accountNumberValue": "123456789",
  "countryCode": "US",
  "street1": "123 Main St",
  "cityCounty": "Miami",
  "stateRegion": "FL",
  "zip": "33101"
}

SWIFT Counterparty Example:

{
  "transferNetwork": "SWIFT",
  "name": "Jane Smith",
  "accountHolderName": "Jane Smith",
  "bicSwiftCode": "BOFAUS33XXX",
  "accountNumberValue": "GB82WEST12345698765432",
  "countryCode": "GB",
  "street1": "10 Downing Street",
  "cityCounty": "London",
  "zip": "SW1A 2AA"
}

Response DTO Enhancements:

Counterparty responses now include additional fields for better visibility:

transferNetwork - The payment network type
routingNumber - ABA routing number (if applicable)
bicSwiftCode - SWIFT/BIC code (if applicable)
bankName - Validated bank name
bankCity - Bank city from validation
bankState - Bank state from validation
bankCountry - Bank country from validation

Change Key​

Changelog​

July 3rd, 2025​

August 11th, 2025​

September 24th, 2025​

October 22nd, 2025​

November 13th, 2025​

November 19th, 2025​

December 3rd, 2025​

December 6th, 2025​

December 8th, 2025​

Change Key

Changelog

July 3rd, 2025

August 11th, 2025

September 24th, 2025

October 22nd, 2025

November 13th, 2025

November 19th, 2025

December 3rd, 2025

December 6th, 2025

December 8th, 2025