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.

• Previous Rate Limits:
  • Production: 100 requests per second universal rate limit across all endpoints and API keys.
  • Sandbox: 25 requests per second universal rate limit across all endpoints and API keys.
• New Rate Limits:
  • Production:
    • 100 requests per second for rate limit across all non-List endpoints.
    • 20 requests per second rate limit across all List endpoints.
  • Sandbox:
    • 25 requests per second for rate limit across all non-List endpoints.
    • 5 requests per second rate limit across all 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.

🧑‍💻 Platform

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.

📚 Ledgers

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.

Upcoming Changes

🧑‍💻 Platform

(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.

• Current Rate Limits:
  • Production: 100 requests per second universal rate limit across all endpoints and API keys.
  • Sandbox: 25 requests per second universal rate limit across all endpoints and API keys.
• New Rate Limits:
  • Production:
    • 100 requests per second for rate limit across all non-List endpoints.
    • 20 requests per second rate limit across all List endpoints.
  • Sandbox:
    • 25 requests per second for rate limit across all non-List endpoints.
    • 5 requests per second rate limit across all 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.

Recently Released

💵 Payments

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.

📚 Ledgers

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.

Recently Released

💵 Payments

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 reversals
• return.created for originated returns
  • You can differentiate from received returns using return.role (originating or receiving)
• incoming_payment_detail.returned_return when an originated return associated with an Incoming Payment Detail is returned itself
  • The linked Incoming Payment Detail will revert to completed or pending

Recently Released

📚 Ledgers

Auto-Ledgering Updates

We made multiple updates to our auto-ledgering functionality to add robustness and improved accuracy to Ledger Transactions linked to payment objects. These updates include:

• effective_at Ledger Transaction timestamp inheritance will now honor the originating bank's timezone.
• effective_at for originated returns will now inherit the reconciled transaction's effective date/time upon posting.
• Originated Returns against IPD's with linked Ledger Transactions will no longer be reversal Ledger Transactions, they will be independent Ledger Transactions representing the cancelling ledger impact of the original Ledger Transaction created from the IPD. This update helps support use cases in which the return is failed and needs to be retried.

✅ Reconciliation

Reconciliation Amounts on Expected Payments

Expected Payment API responses now include amount_reconciled and amount_unreconciled providing insight into the reconciliation status of a given Expected Payment. amount_reconciled, with its direction, represents the total amount that has been reconciled to the Expected Payment. amount_unreconciled, with its direction, is the amount that remains unreconciled for the Expected Payment.

Upcoming Changes

📚 Ledgers

GET Ledger Transactions and Ledger Accounts by External ID

We are expanding our GET endpoints for Ledger Transactions and Ledger Accounts to allow for retrieving resources by external_id. This update allows customers a more efficient pattern to retrieve Modern Treasury resources without needing to use Modern Treasury ID's.

💵 Payments

Enhanced Reporting for CRB Received Payments

Today, MT creates an Incoming Payment Detail when a CRB Wire is Returned. On December 8th, current customers on CRB will be migrated to the following new behavior:

• MT will stop creating Incoming Payment Details for returned CRB Wires
• MT will start creating Returns for returned CRB Wires, which will be linked to the originated Payment Order
• IMAD/OMAD details will be added as Payment References to Received Wires and Returns at CRB

In addition, ACH Incoming Payment Details and Returns will now include ACH trace details as Payment References.

Recently Released

📚 Ledgers

Timezone UI Filters

Within the Ledgers UI, customers now have the ability to specify the timezone they want to perform date/time filtering in. Timezones are set to the user's timezone setting by default, and can be accessed within all date/time filters within the Ledgers UI. Also included is the ability to the timestamp being used for date range filtering.

Ledgers Fund Flows UI Revamp

We've updated our T-Account view within the Fund Flows UI. Customers now have the ability to review the open balances of their Fund Flow for each included Ledger Account. We updated Ledger Account ordering to be alphabetical by default, and have refreshed the UX of the page.

Recently Released

📚 Ledgers

Ledgers Sandbox Templates

The Ledgers sandbox now includes quickstart templates for common use cases to support developers getting up to speed on ledgering and payment flows. Each template is linked to an accompanying documentation guide outlining how to implement the solution.

Ledgers Fund Flows

With Ledgers Fund Flows customers can now visualize their end-to-end payment flows through metadata groupings. Each Fund Flow is dynamically created from pre-existing metadata key-value pairs, and allows you to review the ledger impact of every entry across the corresponding accounts. Fund Flows are available in the Ledgers UI under the ‘Fund Flows’ section.

Filter Ledger Transactions and Entries by Amount

Within the Ledgers UI and API, we now expose filters on Ledger Transaction and Ledger Entry objects by amount. The API filter is available on each object's LIST endpoint, and the UI filters are accessible through the corresponding UI table.

Revamped Create Ledger Transaction UI

We have updated our create Ledger Transaction form within the Ledgers UI. The new for provides a modernized UX while maintaining all core functionality. This release maintains the same functionality of the prior create Ledger Transaction form.

We released enhancements to our Ledger Account and Ledger Account Categories UI's, and have planned upcoming releases across Ledger and Platform.

Recently Released

📚 Ledgers

UI Balance Search by Date

Ledger Account and Ledger Account Category UI’s now have the ability to review their respective balances over a range of dates. After customers select a date range, they are able to review the Available Balance in the embedded chart or select the ‘Table’ option to review all balances over the chosen time frame.

Upcoming Changes

🧑‍💻 Platform

(Anticipated Release 8/18/2025) Reduced Data Retention for Request Logs
Data retention for Request Logs searchable from the UI will be lowered from 4 months to 1 month. Request Logs older than 1 month will continue to be available via CSV export.

📚 Ledgers

UI Timezone Filters

All date filters in the Ledgers UI will have timezones as an option to select and edit. The timezone utilized will be considered when calculating balances and fetching Ledger Transactions or Ledger Entries.

Ledgers Sandbox Updates

Enhanced sandbox experience with embedded documentation, tutorials, and product guides to support your Ledgers exploration and enhance your testing experience.