> ## Documentation Index
> Fetch the complete documentation index at: https://docs.conduit.financial/llms.txt
> Use this file to discover all available pages before exploring further.

# Changelog

> Product updates and announcements

<Update label="February 17, 2026" description="Fixed validation for resident_card KYC documents">
  ### Bug Fix: Resident Card KYC Document Validation

  Fixed a validation issue where `resident_card` documents were incorrectly rejected when uploaded as KYC documents for control persons.

  **What's fixed:**

  * `RESIDENT_CARD` documents are now properly accepted as valid KYC document types in the [Create Document](/api-reference/customers/create-document) endpoint
  * Validation error message updated to include `resident_card` in the list of acceptable KYC document types

  **Impact**: Control persons can now successfully upload resident card documents as proof of identity without encountering validation errors.
</Update>

<Update label="February 11, 2026" description="HKD & SGD now supported for transfers, conversions, and offramps">
  ### HKD & SGD now available for payouts

  Payouts in HKD and SGD are now supported. HKD payouts are available in Hong Kong, and SGD payouts are available in Singapore.

  The `rail` field is now available on the [Create a quote](/api-reference/quotes/create-a-quote) endpoint and is strongly recommended. It will become required in a future release.

  **What’s new:**

  * `SGD` and `HKD` are now supported values in the `target.asset` field of the [Create a quote](/api-reference/quotes/create-a-quote) endpoint
  * A new `rail` field is available on the [Create a quote](/api-reference/quotes/create-a-quote) endpoint. Providing this field is strongly recommended and will become required in a future release.
  * The `target.country` field is now supported and strongly recommended when calling the [Create a quote](/api-reference/quotes/create-a-quote) endpoint. It will become required in a future release.
</Update>

<Update label="February 11, 2026" description="Conditional State, Optional Postal Code, and Numeric State Codes">
  ### Address Field Updates

  **State**: The `state` field is now required only for US addresses and optional for all other countries. State codes can now start with digits (e.g., `03` for Encamp, Andorra).

  **Postal Code**: The `postalCode` field is now optional for all addresses.

  **Key Changes:**

  * `state` is required when `country` is `USA` (ISO 3166-1 alpha-3), optional otherwise
  * `state` accepts numeric-prefixed codes (e.g., `03`, `04`) for jurisdictions like Andorra
  * `postalCode` is optional for all countries
  * Applies to `registeredAddress`, `operatingAddress`, `mailingAddress`, and control person addresses

  **Impact**: Customers can omit postal code when creating or updating. Non-US customers can omit state; US customers must provide state. Numeric state/parish codes are now supported.
</Update>

<Update label="February 5, 2026" description="Unified International Wire Payment Rail">
  ### New `international_wire` Payment Rail

  You can now use `international_wire` as a payment rail when creating bank payment methods for international USD transactions. This removes the need to choose between `swift` and `fedwire` upfront — the appropriate underlying rail is automatically selected at transaction time.

  **What's new:**

  * New `international_wire` value available in the `rail` field of the [Create Payment Method](/api-reference/payment-methods/create-payment-method) endpoint
  * Automatic resolution to the optimal wire transfer method (SWIFT or FEDWIRE) when the transaction is executed

  **Deprecation notice**: The `swift` and `fedwire` rails for international USD payments will be deprecated in a future release. We recommend migrating to `international_wire` for all new integrations.

  **Who is affected**: This feature is being rolled out gradually. Contact your account manager for access.
</Update>

<Update label="February 3, 2026" description="Fixed Customer API Schema Examples and Validation">
  ### Schema Example Improvements

  Fixed validation issues in Customer API schema examples to ensure they comply with all validation rules and can be used directly by developers.

  **Key Changes:**

  * Updated examples to use valid enum values instead of invalid string literals
  * Corrected date formats to match schema requirements (YYYY-MM-DD)
  * Added missing conditional fields required by validation rules to OpenAPI documentation examples

  **Impact**: All schema examples in the OpenAPI documentation now pass validation and can be safely used as reference implementations, improving developer experience.
</Update>

<Update label="February 3, 2026" description=" Breaking Change: Fixed Compliance Requirements Documentation">
  ### ⚠️ Breaking Change: Added new required fields to the Compliance Requirements

  Corrected field requirement documentation in the [Compliance Requirements](/guides/compliance-requirements) guide to accurately reflect the API schema.

  **Key Changes:**

  * Fixed `expectedAverageDailyBalance` field documentation: Changed from Optional to Required
  * Fixed `cashOnHandUsd` field documentation: Changed from Optional to Required
  * Updated `hasUsBankAccount` field documentation: Clarified that it's required for non-US businesses and optional for US businesses

  **Impact**: Developers can now rely on accurate field requirement information when building integrations, reducing validation errors during onboarding.
</Update>

<Update label="January 29, 2026" description="New Customer Enums Reference and Guide Improvements">
  ### Documentation Enhancements

  **New Customer Enums Reference**
  Added a dedicated [Customer Enums](/api-reference/customer-enums) page to the API Reference. This page provides a centralized, comprehensive list of all allowed values for enum fields in the Customer schema, including:

  * Business Classification codes
  * Industry types
  * Stock Exchange lists
  * Regulatory bodies
  * Control Person roles and document types

  **Compliance Requirements Guide Update**
  The [Compliance Requirements](/guides/compliance-requirements) guide has been significantly improved:

  * **Streamlined Layout**: Combined "API Field" and "Condition" columns for better readability.
  * **Direct Links**: Enum fields now link directly to their specific allowed values in the new Customer Enums reference.
  * **Unified Formats**: Standardized table structures across all sections (KYB Documents, Business Form, etc.).
</Update>

<Update label="January 28, 2026" description="Enhanced Date Validation and Terms of Service Requirements">
  ### Date Validation Enhancements

  Added comprehensive date validation rules to ensure data integrity and compliance:

  #### Terms of Service Acceptance

  * `termsOfServiceAcceptance.date` (string): Now validates that the acceptance date cannot be in the future. Must be in YYYY-MM-DD format.
  * `termsOfServiceAcceptance.isAuthenticated` (boolean): Now required to be `true`. Users must be authenticated when accepting terms of service.

  #### Business Information

  * `businessInformation.registeredDate` (string): Now validates that the registration date cannot be in the future. Must be in YYYY-MM-DD format.

  #### Control Person Information

  * `controlPersons[].birthDate` (string): Now validates that the birth date cannot be in the future.
  * `controlPersons[].identityInfo.documentIssueDate` (string): Now validates that the document issue date cannot be in the future.
  * `controlPersons[].identityInfo.documentExpiryDate` (string, optional): Now validates that the document expiry date must be today or in the future (cannot be in the past).

  These validations help ensure that:

  * Terms of service acceptance dates reflect actual acceptance times
  * Business registration dates are historically accurate
  * Control person birth dates are valid
  * Identity document dates are logically consistent (issue date ≤ today ≤ expiry date)
</Update>

<Update label="January 28, 2026" description="Expanded Customer Onboarding Fields">
  ### ⚠️ Breaking Change

  **This update introduces breaking changes to the Create Customer API.** The `businessInformation` object now includes many new required fields. Existing integrations using the Direct Onboarding flow (`onboardingFlow: "direct"`) will need to be updated to include these new fields.

  ### New Business Information Fields

  Added comprehensive new fields to the `businessInformation` object in the Create Customer API to support enhanced KYB/KYC compliance requirements:

  #### Business Classification

  * `hasDBA` (boolean): Indicates if the business operates under a DBA name
  * `businessTradeName` (string, optional): The registered DBA name (required when `hasDBA` is `true`)
  * `isStockExchangeListed` (boolean): Whether the company is publicly listed
  * `stockExchange` (enum, optional): Stock exchange name (required when `isStockExchangeListed` is `true`)
  * `stockExchangeOther` (string, optional): Custom stock exchange name (required when `stockExchange` is `Other`)
  * `tickerSymbol` (string, optional): Company ticker symbol (required when `isStockExchangeListed` is `true`)
  * `entityTaxedAs` (enum, optional): Tax classification (S-Corporation, C-Corporation, Partnership)
  * `taxClassification` (string, optional): Additional tax classification information
  * `describeIndustry` (string, optional): Industry description (required when `industry` is `Other`)

  #### Business Activity & Risk Profile

  * `entityType` (enum, optional): Type of financial entity (Bank, Insurance Company, Securities Broker, etc.)
  * `accountPurpose` (enum): Purpose of the account with Conduit
  * `accountPurposeDescription` (string, optional): Description of goods/services (required when `accountPurpose` is `Payments for Goods or Services`)
  * `productsOrServices` (array): List of products or services the company offers
  * `highRiskIndustry` (enum): High-risk industry exposure
  * `highRiskIndustryDetails` (string, optional): Details about high-risk industry activities (required when `highRiskIndustry` is not `None`)
  * `hasNestedFlows` (boolean): Whether the company operates on behalf of third parties
  * `nestedFlowDescription` (string, optional): Description of third-party flows (required when `hasNestedFlows` is `true`)
  * `certifiesOwnTreasuryUse` (boolean): Certification that accounts will only be used for own treasury management
  * `keyGeographicBusinessCountries` (array): ISO 3166-1 alpha-3 country codes where 20%+ of business is conducted
  * `hasAdvisor` (boolean, optional): Whether the company has a financial or business advisor
  * `regulatorName` (enum, optional): Regulatory authority name (required when `isFinancialInstitution` is `true`)
  * `regulatoryAuthorityOther` (string, optional): Custom regulatory authority (required when `regulatorName` is `Other`)
  * `regulatoryLicenseNumber` (string, optional): License number or registration ID (required when `isFinancialInstitution` is `true`)
  * `hasIndependentAmlAuditReport` (object, optional): Independent AML audit report information
    * `answer` (boolean): Whether company has an independent AML audit report
    * `explanation` (string, optional): Explanation if no audit report (required when `answer` is `false` and `isFinancialInstitution` is `true`)
    * `timeline` (string, optional): Timeline for obtaining audit report (required when `answer` is `false` and `isFinancialInstitution` is `true`)
  * `flowOfFundsDescription` (string, optional): Description of fund flow (required when `isFinancialInstitution` is `false`). Note: Financial institutions must upload a Flow of Funds document instead (see Compliance Requirements guide).

  #### Transaction Volume, Financials & Operations

  * `anticipatedMonthlyVolume` (number): Anticipated average monthly transaction volume in USD
  * `expectedAverageDailyBalance` (number, optional): Expected average daily balance in USD
  * `anticipatedTransactionsVolume` (number): Estimated number of transactions per month
  * `usesBlockChainWallets` (boolean): Whether the company will use blockchain wallet addresses
  * `blockchainWallets` (array, optional): List of blockchain wallet addresses (required when `usesBlockChainWallets` is `true`)
    * `walletAddress` (string): Blockchain wallet address
    * `associatedPlatformType` (enum): Platform type (exchange, custodian, platform, self\_custodied)
    * `associatedPlatformName` (string): Name of the exchange, custodian, or platform
  * `sourceOfFunds` (string): Primary source of funds
  * `isGeneratingRevenues` (boolean): Whether the company is currently generating revenue
  * `revenueCoverage` (enum, optional): Revenue coverage percentage (required when `isGeneratingRevenues` is `true`)
  * `revenueCoverageExplanation` (string, optional): Explanation for low revenue coverage (required when `revenueCoverage` is `Less than 25% of expenses`)
  * `hasInstitutionalInvestors` (boolean): Whether the company has institutional investors (VC or PE)
  * `runwayDurationMonths` (number): Financial runway duration in months
  * `runwayDurationExplanation` (string, optional): Explanation for financial runway (required when `runwayDurationMonths` is less than 12)
  * `cashOnHandUsd` (number, optional): Current cash on hand in USD

  #### Non-US Onboarding Requirements

  * `hasUsBankAccount` (boolean, optional): Whether business has an existing US bank account (required for non-US businesses)
  * `deniedUsBankAccount` (object, optional): Information about denied US bank account (required for non-US businesses)
    * `answer` (boolean): Whether business has been denied a US bank account
    * `explanation` (string, optional): Explanation if denied (required when `answer` is `true`)
  * `businessAuditHistory` (object, optional): Business audit history information (required for non-US businesses)
    * `answer` (boolean): Whether business has audit history
    * `explanation` (string, optional): Details if yes (required when `answer` is `true`)
  * `ownersAuditHistory` (object, optional): Owners audit history information (required for non-US businesses)
    * `answer` (boolean): Whether owners have audit history
    * `explanation` (string, optional): Details if yes (required when `answer` is `true`)
  * `pepInvolved` (object, optional): PEP involvement information (required for non-US businesses)
    * `answer` (boolean): Whether any owner/director/officer is a PEP
    * `explanation` (string, optional): Details if yes (required when `answer` is `true`)

  #### Terms of Service Acceptance

  * `termsOfServiceAcceptance` (object): Terms of service acceptance information
    * `date` (string): Date of acceptance in YYYY-MM-DD format. Cannot be in the future.
    * `ipAddress` (string): IP address of the user accepting terms
    * `isAuthenticated` (boolean): Whether the user was authenticated when accepting. Must be `true`.

  ### API Improvements

  * **Type Safety**: Fixed type compatibility issues where `undefined` values are now properly normalized to `null` for explanation fields in nested objects (`deniedUsBankAccount`, `businessAuditHistory`, `ownersAuditHistory`, `pepInvolved`, `hasIndependentAmlAuditReport`)
  * **Conditional Validation**: Enhanced validation rules to enforce field requirements based on conditional logic (e.g., `regulatorName` required when `isFinancialInstitution` is `true`)
  * **ISO3 Country Codes**: All country-related fields now strictly validate ISO 3166-1 alpha-3 format (e.g., `USA`, `GBR`, `FRA`)

  See the [Compliance Requirements](/guides/compliance-requirements) guide for detailed information about when these fields are required.
</Update>

<Update label="December 15, 2025" description="Compliance requirements, Webhooks, and API Schema updates">
  ### Documentation Updates

  * **Compliance Requirements Guide**: Renamed and expanded the [Compliance Requirements](/guides/compliance-requirements) guide.
    * Added mandatory KYB documents (`SHAREHOLDER_REGISTRY`, `TERMS_OF_SERVICE`).
    * Detailed specific requirements for **Non-US Onboarding**.
    * Explicitly listed `PROOF_OF_ADDRESS` and **Liveness Check** requirements for `AUTHORIZED_REPRESENTATIVE` roles.
  * **Webhooks Reference**: Overhauled the [Webhooks](/developer-sections/webhooks) section.
    * Added comprehensive payload examples for all transaction types (Offramp, Onramp, Deposit, Withdrawal, Conversion).
    * Audited and documented all possible status values for Transactions and Counterparties.
    * Centralized webhook examples to the developer section for better maintainability.

  ### API Schema Improvements

  * **Conditional Validation**: Updated `BusinessInformationSchema` to make `regulatorName` required **only** when `isFinancialInstitution` is `true`.
  * **ISO3 Country Validation**: Enhanced validation for `nationality` and `country` fields to strictly enforce ISO 3166-1 alpha-3 codes.
  * **Schema Refactoring**: Improved internal schema definitions to fix issues with partial updates on refined schemas.
  * **Sandbox API Visibility**: Exposed simulation endpoints (Deposit, Compliance, KYB) in the main API reference for easier integration testing.
</Update>

<Update label="December 11, 2025" description="Customer API documentation updates">
  ### Customer API documentation updates

  Updated the customer API documentation to include more detailed descriptions and summaries for the endpoints.

  Added examples for the request and response bodies for the Create Customer API for Direct Onboarding and Hosted Onboarding options.

  Added examples for the request and response bodies for the Upload KYB/KYC Documents API.

  Fixed bug that caused the KYB and KYC supported document enums not to be showing in the API Reference available options section.

  ### Liveness Check links only returned for authorized representative role

  Liveness Check links will only be returned for control persons with the `authorized_representative` role.

  Added `authorized_representative` role to the API Reference control person role enum.
</Update>

<Update label="November 26, 2025" description="Sandbox URL update">
  ### Sandbox URL update

  Switched the sandbox API base URL in our documentation and API reference to `https://api.sandbox.conduit.financial`.

  Existing sandbox endpoints on prior hostnames remain supported so current integrations continue to work.
</Update>

<Update label="November 17, 2025" description="Customer create field name fix">
  ### Customer create field name fix

  Fixed a typo on the customer create endpoint, renaming the `higRiskIndustry` field to `highRiskIndustry`.
</Update>
