We released several improvements to our payments and ledgers products including API, UI, and webhook updates.

Recently Released

💵 Payments

(Released 6/26/2025) Invoice support for custom issuer name: Customers can now create invoices with customized issuer names. The issuer name is shown on the hosted invoices page and invoice PDF exports. The issuer name can be set during creation through the invoicer_name field and defaults to the name of your Organization in Modern Treasury if not explicitly defined.

(Released 6/25/2025) Exposure of API Bank’s Internal Account ID: We have added a new vendor_id field to represent the ID assigned by API banks for a given account. You can use this ID in both the Internal Accounts API and the UI to assist in polling, since the field maps 1:1 with bank IDs.

📚 Ledgers

(Released 6/30/2025) Updated Filters on Ledgers UI:: We have updated the Ledgers UI to utilize standard modern filters. The updated filters provide a similar filter experience to the rest of the Modern Treasury app and provide customers with the ability to create Saved Views on their Ledgers UI’s.

(Released 6/23/2025) Ledger Account Webhooks:: We have added support for webhooks on Ledger Accounts. Customers can subscribe to receive webhooks over Ledger Account created or updated events. Ledger Accounts will send update webhooks for balance updates or changes to mutable fields (name, description, metadata, etc.).

Upcoming Changes

⭐️ indicates newly introduced upcoming changes

🧑‍💻 Platform

Updates to Java and Kotlin SDKs: There is an upcoming change in our Java/Kotlin API that will be part of a new version release. In this update, we will be replacing an external library (Guava) with a custom solution for handling query parameters and headers. What this means for users:

• Reduced JAR Size: This change reduces the size of the SDK.
• Opt-In Update: Since this is a version change, users will have the option to upgrade at their own pace. The new version will give users access to the improvements, but it won’t affect users who don't choose to move to it.
• Minimal Impact: There may be a small adjustment required for users who have been working directly with raw headers or query parameters.

Optimized High-Volume Payments: Our systems will be optimized to significantly increase the processing speed for large volumes of ACH payments to JPMC.

💵 Payments

⭐️ Faster RTP Completion: We will change the signal used to trigger completion of instant payment rails (type = RTP) to the signal used today for the confirmed event (for PO webhooks). This means these Payment Orders with type RTP will have the confirmed and completed event at the same time.

This will ensure that Payment Order statuses match the instant settlement of these payments without changing reconciliation timeline.

⭐️ More Accurate Cross River Bank Wires Completion Timeline: Modern Treasury will change the trigger for completion of CRB wires to the signal used today for the confirmed event (for PO webhooks). Note that this means reconciliation of these payments will occur before the Payment Order status is moved to completed.

We made this change to account for CRB’s process of posting the wire transaction before confirming the wire will be processed and sent to the recipient.

Payment Batch Metadata via API & Webhooks: We will expose batch-level context in the Payment Order API and webhook events to improve transparency. This will enable faster troubleshooting outside of the UI.

Security Enhancements to External Accounts: It will no longer be possible to create Payment Orders using External Accounts that are in the Pending Approval state. This ensures that payments aren’t sent to External Accounts that haven’t been approved. This change will apply to External Account creation and updates.

Payment Templates: Customers will be able to configure Templates for Payment Orders. Templates allow finance and treasury teams to standardize how payment orders are created by defining preset values, required fields, and locked settings. This structure reduces manual errors, ensures compliance, and makes manual payment processing more efficient.

Increased Importer Speeds for High Volumes: We’re optimizing our system to boost the processing speed of our iso20022, ISO Payment Status, NACHA returns, and BAI2 file importers.

Sunday & Holiday Next Day ACH Processing with JPMC: Next day ACH payments submitted after Friday’s cutoff until 9:50 PM PT on Sunday or during bank holidays will clear by 8:30 AM PT the next business day.

Faster Payments Creation for Larger Volumes: To complement our new Bulk Request API and enhanced file origination performance, we are optimizing our Payment Order creation process. This improvement will significantly increase throughput for high-volume payment creation.

Increased Processing Speed for High Volumes: We’ve optimized our systems to significantly boost the processing speed of large-volume ACH payments across all banks, expanding beyond just JPMC.

Request for Payment (RFP) at PNC: Users will be able to utilize Request for Payment (RFP) on the Real Time Payments (RTP) network at PNC.

Expanded Cross-Border Payment Coverage: We are planning to expand our cross-border payment capabilities at Citi via the Worldlink product and traditional SWIFT wires, adding support for new currencies and countries.

Global Payments Validation: Payment Order fields for cross border payments will automatically be validated against the bank’s requirements for each country and currency. This will notify the user about required fields and the correct format for successful payment completion. For example, this can include Purpose Codes, Tax Identifiers, or Addresses. We will support Global Payments Validations at Bank of America, JP Morgan, and Citi.

Support for Local Payment Methods: We will support local payment methods in India, Japan, and Singapore through Bank of America, further expanding our global reach.

New Bank Integrations: New bank integrations will be added for Regions, Web Bank, and Western Alliance, expanding banking options for users.

✅ Reconciliation

⭐️ External_idon Expected Payments : We will support a unique external_id field on Expected Payments, as we do on several objects.

Incoming Payment Detail<>Transaction Reconciliation Update : When an IPD and Transaction are reconciled, the IPD will always appear under a Transaction's Related Items, not Reconciled Items. This linkage will not mark the Transaction as reconciled or partially reconciled. Note that this change has already been applied to some users.

Paper Item Deprecation: Users will no longer see Paper Items in the UI; all related functionality will be transitioned to Incoming Payments of type Check. More details to come; please contact support if you have any questions.

Faster High-Volume Recon: We will launch system improvements to process reconciliations faster when handling high transaction volume.

📚 Ledgers

Creating LTs on Lock Failure: We plan to add an archive_on_lock_failure parameter on Ledger Transaction Creation. If a Ledger Transaction is created with this parameter and fails due to an insufficient balance, an archived Ledger Transaction will be created, recording the failure. This is useful for cases like card authorization to record failed authorizations.

External_idon Ledger Accounts : We will support a unique external_id field on Ledger Accounts, as we do on Ledger Transactions.