Added

17 August 2026

⚠️ Deprecations

  1. Compliance API — the top-level failureCode on attestation validation failures. Sunset 21 August 2026 EOD. A validation failure on a compliance review attestation now carries a failureInfo object discriminated on failureCode. The top-level failureCode still returns the same value for released clients, but it only mirrors failureInfo.failureCode. Read the code from failureInfo going forward.
  2. Compliance API — primaryAccountPurpose: "OTHER". Sunset 21 August 2026 EOD. OTHER and its companion field primaryAccountPurposeOther are deprecated; submit the closest supported purpose instead. After the sunset date, OTHER returns a 400. See Upload attestations.
  3. Compliance API — OTHER values on latestOccupation. Sunset 21 August 2026 EOD. All OTHER / OTHER_* values, along with latestOccupationDescription, are being removed; use one of the 392 supported occupations. Deprecated values return a 400 after the sunset date. See Upload attestations.
  4. Accounts API — accountDetails.depositAccount. Sunset 4 September 2026 EOD. Applies to GET /api/accounts and GET /api/accounts/{id}; use accountDetails.payinMethods[] instead. It is already in responses today, so you can migrate now. Deprecated since 24 June 2025.
  5. Payouts API — payouts[].amount. Sunset 25 September 2026 EOD. On POST /api/payouts/payout, the source-denominated amount is deprecated in favor of amountV2, which also supports target amounts. Send exactly one of the two. Note the shape change: value is a minor-unit string, and the token moves into sourceCurrency.

🚀 New APIs

  1. Programmatic RFIs — answer a compliance request for information over the API. A review in additionalInformationRequested now carries an rfiId. Use it to read the request (GET /api/compliance/{organizationId}/rfis/{rfiId}), upload the answer (PUT /api/compliance/{organizationId}/rfis/{rfiId}/attestations), and submit it (POST /api/compliance/{organizationId}/rfis/{rfiId}/submit). Each requested item states its scope — the whole attestation, or named fields — with a machine-readable reason code, and a field-scoped answer merges onto the attestation's current values rather than replacing them. There is no RFI webhook yet, so poll the RFI or the review status. See Responding to RFIs

🌐 New Routes

  1. USDT0 on Plasma — USD on-ramps and off-ramps. An account holding USDT0 on Plasma can now fund from USD and pay out to USD. This is enabled per organization. Reach out to [email protected] if you want Plasma enabled.

⭐ Enhancements

  1. Compliance API — address validation on attestations. Address-bearing attestations (individualResidentialAddress, individualPersonalInfoLight, businessAddress) are now validated against the Google Address Validation API on upload. Failures are always WARNING severity — you can acknowledge them at submit — so an unverifiable address never blocks a review on its own. Each failure returns severity, an optional field naming the attestation payload field, and a failureInfo union. A suggested correction carries submittedAddress and suggestedAddress, which you can resubmit as-is. Associated person (UBO) attestations are not validated yet.
  2. Payouts API — target-amount payouts. Specify the exact amount your recipient receives and Mural solves for the source debit. Each payout in POST /api/payouts/payout now accepts amountV2, with type: "sourceAmount" (you set what is debited) or type: "targetAmount" (you set what lands). value is a minor-unit string ("15000" = 150.00), and sourceCurrency names what to debit — a fiat balance or a stablecoin. Target amounts are fiat payouts only, and the existing amount field still works but is deprecated — send exactly one of the two.

🐛 Bug Fixes

  1. The LIGHT-tier KYC threshold counts payouts only. The lifetime payout limit that triggers a KYC upgrade previously summed every transfer associated with an organization, in both directions, so inbound deposits and transfers between an organization's own accounts counted toward it. Usage is now outbound value only.