The GET /internal_accounts/:id/balance_reports endpoint now orders results by as_of_date and as_of_time (bank-reported time) instead of as_of_date and created_at (ingestion time). This more accurately reflects the chronology of balance reports reported by the bank.
Simulate ACH NOC Returns in Sandbox
Users can now simulate ACH NOC (Notification of Change) returns in the sandbox environment by passing a specific counterparty account number when creating a payment order, consistent with existing ACH and wire return simulation.
Upcoming Changes
💵 Payments
(Releasing May 11, 2026)Counterparty Requirement for MT Payment Accounts
Payment Orders originating from PSP internal accounts now require the receiving external account to be linked to a counterparty. Inline External Account creation on Payment Orders is no longer supported for PSP connections.
In the dashboard, External Accounts without a Counterparty are disabled in the Receiving Account selector when creating a PSP Payment Order.
(Releasing May 18, 2026)PSP Internal Accounts will not support setting party_name
Customers will no longer be able to set party_name when creating Internal Accounts. Moving forward Internal Accounts will inherit the full name (first_name and last_name ) for accounts linked to individual Legal Entities and business_name for accounts linked to business Legal Entities. This change helps ensure accurate naming across customer accounts.
If party_name is present on an Internal Account creation request Modern Treasury will prevent the creation and return a 422 error response. In order to prevent disruptions with your integration create your Internal Accounts without passing in party_name.
(Releasing ~05/15/2026) Legal Entity Object Updates - Third Party Verifications: We are making a change to the third_party_verification object within the legal entity object. The changes include:
Renaming the parameter to third_party_verifications
Adjusting the parameter to be an array of objects
To avoid any issues with your integration please take the following actions:
If you are creating legal entities with a third_party_verification object you will need to adapt your request to utilize the new third_party_verifications parameter.
If you are consuming the entire body of the legal entity response or webhooks you will need to adjust your integration to account for the new third_party_verifications parameter instead of the legacy third_party_verification parameter.
Modern Treasury now fully supports stablecoin money movement as a native payment type alongside ACH, Wire, RTP, and Book Transfers — no separate crypto stack, no separate mental model. You use the same primitives you already know (Internal Accounts, Counterparties, Payment Orders, Incoming Payment Details, Transactions) to send, receive, and reconcile stablecoin flows.
What's new:
Getting started
New to stablecoins on Modern Treasury? Start with the Stablecoin overview, then pick On-Ramp or Off-Ramp depending on your flow.
Already a live PSP customer? Create a stablecoin-enabled Internal Account, add a stablecoin External Account to your existing Counterparty, and reuse your existing Payment Order integration.
Questions or access requests? Reach out to your Modern Treasury contact — we'll get you provisioned in sandbox and production.
Stablecoin Internal Accounts. Create a stablecoin-denominated Internal Account (e.g. currency: "USDC") the same way you create a USD account. Balances, transactions, and reconciliation all work end-to-end.
Stablecoin Counterparties & External Accounts. Attach on-chain addresses to a Counterparty's External Account to send or receive stablecoin payments.
Send a stablecoin Payment Order. Originate stablecoin payments using the existing Payment Order API.
Receive stablecoin payments. Inbound on-chain transfers are surfaced as Incoming Payment Details (IPDs) with type: "stablecoin" and a subtype identifying the network (e.g. ethereum, solana, base, polygon). You can filter IPD lists by subtype to segment by network.
Supported stablecoins & networks:
Stablecoin
Ethereum
Solana
Base
Polygon PoS
Arbitrum One
Stellar
USD Coin (USDC)
Yes
Yes
Yes
Yes
—
—
PayPal USD (PYUSD)
Yes
Yes
—
—
Yes
Yes
Global Dollar (USDG)
Yes
Yes
—
—
—
—
Pax Dollar (USDP)
Yes
Yes
—
—
—
—
Tether (USDT)
Coming soon
New: Stablecoin Orchestration
In addition to sending and receiving stablecoins directly, you can now orchestrate conversions between fiat USD and stablecoins through Modern Treasury:
On-Ramp — convert incoming USD (ACH, Wire, RTP) into stablecoin in a stablecoin Internal Account, then optionally forward it on-chain to a counterparty.
Off-Ramp — convert incoming stablecoin into USD in a fiat Internal Account, then optionally forward it via ACH, Wire, or RTP to a counterparty.
Both flows are built on the existing Book Transfer and Payment Order primitives, so reconciliation, webhooks, ledgering, and audit trails behave exactly like any other orchestrated payment.
Highlights:
Unified orchestration — one workflow spans the fiat leg, the conversion, and the on-chain leg.
End-to-end visibility across IPDs, Book Transfers, and Payment Orders via Transactions and webhooks.
Works with your existing counterparty model — no parallel schema for "crypto vs. fiat" parties.
See the new Stablecoin On-Ramp and Stablecoin Off-Ramp guides under Orchestration in the API docs (replacing the interim PDF quickstarts previously shared with early-access customers).
Updated API documentation
The API reference and guides have been restructured so stablecoin is discoverable in the same place you look for any other rail:
Originating payments → ACH, RTP, Wires, Book Transfers, Stablecoin
The prior standalone "Original Stablecoins" section has been retired in favor of this integrated structure.
SDK support across every official SDK
The Modern Treasury backend has supported creating stablecoin Internal Accounts (USDC, USDG, PYUSD, etc.) on Paxos and MT Flow for some time, but the OpenAPI spec hardcoded internal_account_create_request.currency to USD/CAD. Because our SDKs are generated from that spec via Stainless, none of them exposed stablecoin currencies — customers had to hand-roll raw HTTP calls to create a stablecoin Internal Account from an SDK-based integration.
That gap is now closed. The OpenAPI spec now accepts the full stablecoin currency set on Internal Account creation, and the fix has propagated to all official SDKs:
Go — modern-treasury-go v2.51.0
Python — modern-treasury-python
Node / TypeScript — modern-treasury-node
Ruby — modern-treasury-ruby
Java — modern-treasury-java
Kotlin — modern-treasury-kotlin
Across all SDKs, the same generation cycle also surfaces:
The new stablecoin value on the Incoming Payment Detail type enum (plus matching list-filter and async-create params).
The new subtype field on Incoming Payment Details — an additional classification layer; for a type of stablecoin, the subtype identifies the network (e.g. ethereum, solana, base, polygon).
Related stablecoin-aware updates to PaymentOrder, PaymentReference, Return, InternalAccount, and Invoice types.
If you're on an older SDK version, upgrade to the latest release of your language's SDK to get stablecoin support out of the box.
We have introduced a uniqueness requirement for legal entity TIN (tax identification number- SSN, TIN) numbers. This change will prevent legal entities with the same tax identification numbers to be created. The introduction of this change allows for customers to re-use individual legal entities as beneficial owners or control persons across multiple business legal entities.
When creating a business legal entity that shares a beneficial owner or control person with another business legal entity, you can simply pass in the legal entity ID in the business legal entity creation request.
Upcoming Changes
💵 Payments
(Releasing 05/11/2026)Counterparty Requirement for MT Payment Accounts
Payment Orders originating from PSP internal accounts now require the receiving external account to be linked to a counterparty. Inline External Account creation on Payment Orders is no longer supported for PSP connections.
In the dashboard, External Accounts without a Counterparty are disabled in the Receiving Account selector when creating a PSP Payment Order.
Push To Warehouse (PTW) Stringified Ledger Entry Columns: We’ve introduce the following 5 new columns on our PTW Ledger Entry schema:
posted_debits_string
posted_credits_string
pending_debits_string
pending_credits_string
amount_decimal_string
These string variants are provided to support values with precision exceeding 19 digits before the decimal point; a range the existing numeric columns cannot represent. For such values, the non-stringified columns will be NULL.
Upcoming Changes
🧑💻 Platform
(To be released 04/03/2026)Push To Warehouse (PTW) Stringified Transaction Column: We’re introducing one new column on our PTW Transaction schema:
amount_string
This string variant column is provided to support values with precision exceeding 18 digits before the decimal point; a range the existing bigint column cannot accurately represent. For such values, the non-stringified columns will be NULL.
(Released 3/27/2026)Legal Entity Sandbox Simulation Endpoints: We've added the ability for customers to simulate legal entity status transitions within Sandbox. This enables PSP customers to test their end to end onboarding workflows accounting for all valid legal entity status transitions. For more information please refer to the following docs:
We released several improvements to our payments and ledgers products including API, UI, and webhook updates.
Recently Released
💵 Payments
(Released 2/27/2026)Batch ID on Payment Orders: Payment Orders now include a batch_id, allowing you to see exactly which batch a payment was sent in and navigate directly to the associated outbound file to review all payments in that batch. This makes it easier to debug bank issues, reconcile downstream systems, and self-serve without relying on Support. We’ve also improved performance when loading batch data, so you can quickly view payments even for large batches.
✅ Reconciliation
(Released 2/27/2026)Intracompany Transfers: Receiving Account Reconciliation Event: We’ve introduced a new payment_order.receiving_account_reconciled event for payments between your internal accounts. This event indicates that funds have posted in the receiving account, including transfers across different banks, without affecting the Payment Order state. This provides a clear, reliable signal for the receiving side of internal transfers, enabling more precise automation, such as triggering ledger updates or downstream workflows when funds arrive.
Upcoming Changes
💵 Payments
(Releasing ~04/01/2026)The Sandbox Incoming Payment Detail Simulation Endpoint Now Returns a Full IPD Object: When using the Simulate IPD endpoint (available in sandbox), the full IPD structure is returned, not just an object id and object type. The full object response includes the same parameters of object and id that the endpoint supported before this change.
(Releasing ~04/01/02026)Sandbox Payments process more quickly: In all payment sandboxes, payments move from approved to processing immediately. Previously, ACH payments would remain in approved for several minutes before moving to processing and sent. This makes it easier and faster to test payment lifecycles in the sandbox before moving to production.
✅ Reconciliation
(Releasing ~3/30/2026)Reconciliation Rules Deactivation: We’re making a small update to how reconciliation rules are managed to help keep performance fast and reliable.
From 3/30, any reconciliation rule that has not matched a transaction in the past 90 days will be automatically deactivated. This change helps reduce unnecessary processing and ensures active rules continue to run efficiently.
No action is needed if you’re comfortable with inactive rules being deactivated. If you’d prefer to keep certain rules active, we recommend reviewing them before the change takes effect.
Deactivated rules are not deleted. You can re-enable them at any time from the Reconciliation Rules page.
For more details on how reconciliation rules work and the deactivation criteria, please visit our documentation: Reconciliation Rules
(Releasing ~04/01/2026)Date Requirements for Expected Payments and Reconciliation Rules: Expected Payments and Expected Payment Reconciliation Rules now require date bounds to ensure fast, predictable matching as volumes grow. This prevents unbounded searches that can slow reconciliation and impact downstream workflows, improving overall reliability and consistency of reconciliation performance.
🧑💻 Platform
(Releasing ~04/19/2026)Changes to Webhook Retry and Notification Policy: Webhook deliveries will retry up to 14 times over approximately 1 day using exponential backoff. All organization admins will receive email notifications as retries progress, so they can investigate and resolve the issue.
Webhook endpoints will be automatically disabled if all retries fail, reducing the retry window from 4 days to 1 day and enabling faster issue detection and resolution.
(Releasing ~05/09/2026)Faster Pagination Behavior: Paginated API responses will no longer return empty final pages, reducing unnecessary requests and improving performance.
Ensure your integration correctly handles the updated pagination behavior. If utilizing an SDK, upgrade to the minimum supported SDK versions before May 9, 2026 to avoid issues.
We have removed the three character validation for custom currencies. Customers can now utilize custom currencies that are outside the bounds of standard currency formatting such as digital assets.
While we work on enhancing this feature, will be removing the banner that appears on the Create Payment Order page in the Modern Treasury app (see image below). Customers can continue to refer to the Processing Windows in the Accounts tab, and the Payment Order's Effective Date to determine the timing of your Payment Order processing.
Customers can now review their legal entities in the Modern Treasury app. The read-only UI is accessible for Payments customers via the side navigation bar. Within the details view of a given legal entity the related counterparty and account information is linked. In addition to the standalone UI we have added legal entities to the internal accounts UI allowing for review of legal entities related to a specific account.
Access to view legal entities can be adjusted via roles and permissions settings.
