Payment order timing banner
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.
Legal Entities UI
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.
Ledger Account Category Balance Amount Filtering
Ledger Account Categories now support filter by balance amounts for all balance types, pending_balance_amount, posted_balance_amount, and available_balance_amount, in the Ledger Account Categories UI as well as on the List Ledger Account Categories endpoint.
To utilize the filters via API users can include the balance amount object(s) of their choosing as request parameters.
Updates to assets.moderntreasury.com/uploads/ip-ranges.json
We added additional IP ranges in https://assets.moderntreasury.com/uploads/ip-ranges.json, and changed the schema of the JSON file.
Modern Treasury IP ranges are also published at https://docs.moderntreasury.com/platform/reference/ip-addresses.
Updates to Rate Limits: We have updated how List endpoints are rate-limited. These updates allow us to provide improved reliability and performance on search activity both in the UI and API, while providing more throughput for core write and read operations.
We introduced a new 20 requests per second rate limit across all List endpoints in Production, and a 5 requests per second rate limit across all List endpoints in Sandbox. The default 100 requests per second limit in Production, and 25 requests per second limit in Sandbox remains for all non-List endpoints.
We have reviewed all customer API traffic patterns and have concluded that the new List endpoint rate limits will impact a very small subset of customers that will be able to utilize alternative patterns to power their integrations.
In the event that you do breach the new rate limit you will receive 429 errors in the same way that our standard rate limit operates.
We recommend building processes that consider our rate limits as upper bounds across your services. Please reference our rate limit documentation for recommendations on integrating to Modern Treasury with rate limits in mind.
Updates to Response Headers for Paginated Results
We have updated our response headers to exclude X-After-Cursorwhen there are no more additional pages of results to retrieve. More information can be found in our pagination documentation.
Auto-Ledgering Incoming Payments for Internal Accounts and Nested Internal Accounts
We have added support for auto-ledgering inbound payments on Internal Accounts and Nested Internal Accounts. This update provides automated payment attribution ledgering for customers who utilize Nested Internal Accounts to represent their banks' Virtual Accounts. Customers also now have the ability to auto-ledger payments sent to their Internal Accounts irregardless of their Virtual Account setup to help ensure that all payment activity within their account is represented on their Ledger.
Please refer to our guide for linking Ledger Accounts to Internal Accounts for more details on the auto-ledgering behavior and how to enable the functionality.
(To be released 12/12/2025)Updates to Rate Limits: We are updating how List endpoints are rate-limited. These updates allow us to provide improved reliability and performance on search activity both in the UI and API, while providing more throughput for core write and read operations.
We are introducing a new 20 requests per second rate limit across all List endpoints in Production, and a 5 requests per second rate limit across all List endpoints in Sandbox. The default 100 requests per second limit in Production, and 25 requests per second limit in Sandbox remains for all non-List endpoints.
We have reviewed all customer API traffic patterns and have concluded that the new List endpoint rate limits will impact a very small subset of customers that will be able to utilize alternative patterns to power their integrations.
In the event that you do breach the new rate limit you will receive 429 errors in the same way that our standard rate limit operates.
We recommend building processes that consider our rate limits as upper bounds across your services. Please reference our rate limit documentation for recommendations on integrating to Modern Treasury with rate limits in mind.
Updating Timing for Returned Incoming Payment Details
When originating Returns, Incoming Payment Details will have their status updated to returned if and when the associated Return succeeds at the bank. Previously the status change had occurred upon return creation.
If the Originated Return fails, the associated Incoming Payment Detail will revert to completed status.
Get Ledger Transactions and Ledger Accounts by External ID
Ledger Accounts and Ledger Transactions now support Get by external_id. This update allows customers to use their internal reference ID's to directly query common Ledgers objects, providing a more efficient API pattern for integrations that do not store Modern Treasury ID's.
Flagging Bank Holds on Payment Orders
Bring your own Bank can now move any Payment Order that has been sent to held status to inform internal teams and your end users that the payment has been stopped in transit. Note that managing holds in Modern Treasury has no impact on the movement of funds, it is purely for reporting and visibility purposes.
Holds can be manually or automatically resolved depending on bank signals received, and allow for a description (reason) to be associated with the initial hold and hold resolution.
For more details, you can review our guide on managing bank holds.
Note: Use of this feature introduces a new state and state transitions for Payment Orders, which may impact your internal systems if not accounted for.
New Webhook Events for Returns and Reversals
We are introducing new events related to returns and reversals to provide more visibility and standardization across these objects.
reversal.created for originated reversalsreturn.created for originated returns
return.role (originating or receiving)incoming_payment_detail.returned_return when an originated return associated with an Incoming Payment Detail is returned itself
completed or pending