Added

01 September 2026

🌐 New Routes

  1. USD international wire payouts. You can now wire USD to a beneficiary bank outside the US. Create the payout method with type: "usdInternationalWire" on POST /api/counterparties/{id}/payout-methods, addressing the beneficiary bank by swiftBic and supplying bankName and bankAccountNumber (an account number or IBAN). Supply intermediaryRoutingNumber when the beneficiary bank requires a named correspondent bank. This is enabled per organization — reach out to [email protected] if you want it turned on.

⭐ Enhancements

  1. Compliance API — offshore jurisdictions are now supported for business compliance reviews. Cayman Islands, British Virgin Islands, Bermuda, Turks and Caicos, Anguilla, Jersey, Guernsey, Isle of Man, Gibraltar, and Mauritius now have tax ID allowlists. Jurisdictions that issue no standard TIN accept the Company/Registration Number (CRN); the Crown dependencies and Gibraltar accept CRN and TIN. A country with no allowlist entry no longer fails every tax ID type at submission. See Upload attestations.
  2. Payouts API — developer fees are now rejected up front for organizations without a parent. Payouts carrying developerFee.developerFeePercentage are validated on POST /api/payouts/payout and return 400 when the paying organization has no parent organization. Retry on behalf of a child organization using the on-behalf-of header. Eligibility follows the paying organization's actual parent rather than the header, so a child organization calling with its own API key can still collect developer fees. A developerFeePercentage of 0 counts as no developer fee and is unaffected.
  3. Accounts API — set settlement strategy returns 412 instead of 500 for unsupported organizations. PUT /api/accounts/{id}/set-settlement-strategy now returns a typed SettlementStrategyNotSupportedException when the organization's provider does not support settlement strategies, or when the organization is not approved for that provider, instead of an internal server error.

🐛 Bug Fixes

  1. Compliance API — address validation no longer flags cosmetic differences as corrections. An address that Google merely reformats (ZIP+4 expansion, inferred administrative regions, casing or punctuation) no longer produces a SUGGESTED_CORRECTION warning on attestation upload. Only material corrections, such as a replaced postal code, are surfaced.