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.

Ensure endpoints return timely 2xx responses and review our documentation: Webhook Endpoint Best Practices

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

📚 Ledgers

Custom Currency Validation Update

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.

💵 Payments

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.

💵 Payments

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.

📚 Ledgers

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.

🧑‍💻 Platform

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.

🧑‍💻 Platform

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.