Current Product Release Notes and Schedule

2026R1

07 Feb 2626

14 Feb 2026

2026R2

07 Mar 2026

14 Mar 2026

2026R3

04 Apr 2026

11 Apr 2026

2026R4

02 May 2026

09 May 2026

2026R5

30 May 2026

06 Jun 2026

2026R6

27 Jun 2026

11 Jul 2026

2026R7

25 Jul 2026

08 Aug 2026

2026R8

22 Aug 2026

05 Sep 2026

2026R9

19 Sep 2026

03 Oct 2026

2026R10

17 Oct 2026

24 Oct 2026

2026R11

14 Nov 2026

21 Nov 2026

2026R12

12 Dec 2026

09 Jan 2027

2026R13

09 Jan 2027

16 Jan 2027

Enhancement

LQTY-561

FX Rate Groups

The FX Settings tab in Worksheet Setup is now editable in the new Liquidity UI.

• Seven editable drop-downs: Currency Equivalent, plus Rate Scenario and Rate Source for each of Actual, Estimated, and Forecast.

• Each dropdown opens on the worksheet’s saved value; option lists come from database reference data.

• Rate Scenario and Rate Source are independent. Changing one doesn't affect the other.

• Selecting the blank option clears the field.

• FX changes are saved with the rest of the Worksheet Setup form (no separate FX save); Cancel discards them.

• If a Currency Equivalent is set, the scenario and source are required for each allowed value type. Otherwise the save is rejected with a message on the fields that need a value.

Enhancement

159100

Add Comments on the Balance View (Native)

You can now add comments to a balance directly from the Balance view. Existing comments are listed, and a new comment (up to 4,000 characters, with a remaining-character count) appears in the list as soon as it is saved. No separate pop-up and no page reload. Empty comments are rejected and any save problem is reported on screen.

Available under the new Worksheets menu, switched on per company. Contact Ripple Treasury Support to have it turned on. The existing Worksheets menu is unchanged.

Enhancement

162720

Proposals Config: Numeric Entry, Worksheet Currency Scope, and Covenant Dialog Defects

Proposals configuration corrections: numeric fields accept decimal and negative entry as expected, worksheet options are limited to the currencies in scope for the selected worksheet, and the covenant dialog opens with the correct defaults. Part of the GSmart Liquidity Proposals feature, which remains behind a feature flag that is off by default.

Enhancement

RECO-374

See filtered-out records alongside exceptions

Records that your rules filtered out didn't show up anywhere, so you couldn't tell whether a missing record was filtered out or a real exception. They now appear in the exceptions view, marked so you can tell them apart.

Enhancement

RECO-371

Filter the audit log, and see a summary

You can now filter the audit log down to the events you're looking for. A summary panel shows recent activity at a glance.

Enhancement

RECO-287

Rules can't sum text columns.

We now catch rules that try to sum or aggregate a text column before they can fail a run.

Enhancement

RECO-103

Set column data types when creating a dataset.

You can now set each column's data type — text, number, date, or true/false — in the UI when you create a dataset. We detect the types automatically and pre-fills them, so usually you just confirm.

Enhancement

RECO-95

Delete records from a dataset.

Before, removing records meant deleting the whole dataset and uploading it again. Now you can remove records from an existing dataset.

Enhancement

RECO-361

Live progress during a match run.

The job log now shows real-time progress from the matching engine while your reconciliation runs. You no longer have to wonder whether a large run is still working.

Enhancement

RECO-66

Rule problems are caught before the run starts.

If a rule tries to sum a column that holds dates, times, or true/false values, We flag it upfront with a clear message instead of letting the run fail partway through.

Enhancement

RECO-242

Faster reconciliation list.

The reconciliations page loads in pages behind the scenes, so it opens quickly no matter how many reconciliations your team has.

Fixed

RECO-305

No more accidental double-runs.

If a reconciliation is already running, the system now prevents a second run from starting on it until the first one finishes.

Enhancement

Faster, Bulk Line Item Assignment

You can now assign line items to multiple business units (and business units to multiple line items) in a single action, rather than one at a time. This makes setting up and adjusting your forecasting model significantly quicker for larger structures.

Enhancement

Faster Report Generation

We've reworked how reports are calculated behind the scenes - reusing a single shared calculation across an expanded report instead of recalculating for every row. Large reports (especially expanded/comparison exports) now generate noticeably faster and are less likely to time out.

Enhancement

Improved Application Reliability and Observability & Performance

Behind-the-scenes improvements to our background processing have removed a job that could consume excessive server resources for hours, and we've strengthened our New Relic monitoring and observability so we can detect and resolve issues faster - resulting in a smoother, more stable experience.

Enhancement

Stronger Security & Data Protection

We completed a major security hardening initiative following independent penetration testing, closing a range of potential vulnerabilities and further protecting your data across the platform.

Fixed

PYMT-327

ACK File Cleanup Fails Due to Session Expiry on Long-Running Jobs, Causing Infinite Reprocessing Loop

We identified and fixed an issue where payment acknowledgement (ACK) files from certain large batch jobs were not being cleared from processing after completion. In some cases, this caused the same files to be reprocessed repeatedly rather than being finalized.

What changed: Payment acknowledgement processing now correctly completes and clears files at the end of a job, regardless of how long the job takes to run. This eliminates unnecessary repeat processing and reduces load on the platform.

Impact to you: No action is required. You may notice improved processing reliability for larger ACK file volumes going forward.

Enhancement

161875

Login: Update Message on Suspended User Pop-Up

This updates the login message displayed to suspended AFX users, aligning it with the AFX Password Reset feature.

Fixed

110295

SSO: Turn Off Case Sensitivity for operatorID Attribute

This change makes the handling of the operatorID attribute case-insensitive.

Fixed

161853

Password Reset Page Served from Browser Cache After Successful Use: “Change Password” Form Displayed Instead of Invalid-Link Message

This fix addresses the issue of used password reset links being cached by the browser.

Enhancement

157641

Fix FX Dashboard Market Rate Quotation Direction to Match Hedge Rate Convention

The FX Dashboard has been enhanced to ensure that market rates and hedge rates are presented using the same quotation convention. This provides clearer rate comparisons and more consistent gain and loss and market valuation information across the FX Exposures and Hedges Summary.

Previously, for certain currency pairs, the Market Rate could be displayed in the opposite quotation direction to the Avg Rate of Hedges, making direct comparison between market and hedge rates difficult.

The Market Rate now follows the quotation method configured for the currency pair in Currencies, consistent with Avg Rate of Hedges and other rate-based information displayed on the dashboard.

As a result, related calculations and comparisons, including Hedges Gain and Loss, Proposed Full Hedge Rate, and unhedged exposure valuations, now use market rates presented on the same basis as hedge rates.

Forward market rates have also been enhanced for currencies configured to use OIS discounting, ensuring the appropriate discounting basis is reflected in forward-rate calculations.

Existing exposures, hedges, and currency-pair configurations are unchanged.

Impact to users:

• No action is required. The enhancement is applied automatically and does not require any new configuration.

• Users may notice changes to the displayed Market Rate and related values for currency pairs that were previously shown using the opposite quotation direction. Clients using currencies configured for OIS discounting may also see small changes in forward market rates and values derived from them.

• If your organization has used manual calculations or spreadsheet adjustments to reverse Market Rates previously displayed by the FX Dashboard, we recommend reviewing these workarounds, as they may no longer be required.

Who is affected:

• This enhancement applies to clients using the FX Dashboard — FX Exposures and Hedges Summary, particularly where:

  • Currency pairs are configured with direct or indirect quotation methods

  • Currencies use OIS discounting for forward-rate calculations

• Deal entry, hedge booking, exposure management, and existing currency-pair configuration are not affected.

Recommendation:

• We recommend reviewing the FX Exposures and Hedges Summary for your commonly used currency pairs and confirming that the quotation method configured in Currencies reflects your organization's preferred rate presentation.

• Where manual workarounds were previously used to adjust Market Rate quotation direction, these should also be reviewed and removed where no longer required.

• For further assistance, please contact your Ripple Treasury representative.

Enhancement

154150

Fix ABS First-Period Interest Calculation When Renegotiation Occurs Before First Payment Date

Interest calculation has been enhanced for Asset Backed Securities (ABS) where a drawdown or principal repayment occurs before the first interest payment date.

The first interest period now reflects the principal balance applicable before and after the renegotiation, providing more accurate interest, accrual, and financial event values.

Previously, where an ABS deal was renegotiated during its first interest period, the revised principal balance could be applied across the entire period.

With this enhancement, the first interest period is now calculated using the appropriate principal balance for each part of the period:

• the original principal balance applies up to the renegotiation date

• the revised principal balance applies from the renegotiation date onwards

The resulting amounts are combined to produce the first-period interest value.

Related accruals and financial events now reflect the corrected calculation, and residual Pending balance entries associated with these scenarios are no longer retained on the Events tab.

There is no change to subsequent interest periods, ABS deals without a renegotiation during the first period, or other security types.

Impact to users:

• No action is required to enable this enhancement.

• For affected ABS deals, first-period interest, accruals, and related financial events may change when events are regenerated. The resulting amount may be higher or lower depending on whether the renegotiation increased or reduced the principal balance.

• There are no changes to deal capture, renegotiation workflows, screens, or data-entry steps.

• Existing deals are not automatically recalculated. Where an affected deal is regenerated after the upgrade, the corrected first-period values will apply. If the deal has already been settled, reported, or posted to accounting, we recommend reviewing the impact before making any downstream adjustments.

Who is affected:

• This enhancement applies to clients using Asset Backed Securities where a drawdown or principal repayment occurs before the first interest payment date.

• The following are not affected:

  • ABS deals with no renegotiation during the first interest period

  • interest periods after the first payment date

  • Bonds, Floating Rate Notes, and other security types

Recommendation:

• We recommend reviewing affected ABS deals after the upgrade, particularly where financial events are regenerated for a deal with an early drawdown or principal repayment.

• For deals that have already been settled, reported, or posted to accounting, review any resulting differences before processing adjustments.

• For further assistance, please contact your Ripple Treasury representative.

Enhancement

157402

Fix Missing Equity Balance GL Postings After FX Hedge Relationship Termination

Hedge accounting has been enhanced to maintain equity balance postings after an FX hedge relationship is de-designated, terminated, or fully transitioned to fair value before the remaining equity balance is released.

This provides more complete GL Processing output and helps ensure deferred equity balances continue to reconcile with hedge accounting reports throughout the remaining reclassification period.

Previously, where an FX hedge relationship ended before its remaining equity balance was scheduled for reclassification, GL Processing might not produce equity balance entries for the accounting periods between the termination or de-designation date and the final release of that balance.

With this enhancement, equity balance entries continue to be generated for each applicable accounting period while the balance remains deferred in equity.

Reversing entries also continue only for as long as the deferred balance remains outstanding. Once the applicable reclassification date is reached, the reversing entries stop and the equity balance is released through the standard reclassification process.

This behavior applies consistently across supported equity release schedules, including single-date releases, straight-line amortization, and effective-rate amortization.

Existing hedge accounting configurations and GL mappings are preserved, and periods that were already processed correctly are unchanged.

Impact to users:

• No configuration changes are required.

• Clients may see additional equity-related journal entries in GL Processing for periods between the termination or de-designation of an affected hedge relationship and the subsequent equity reclassification date.

• Where manual journals have previously been used to maintain the deferred equity balance during these periods, we recommend reviewing those workarounds to avoid duplicate postings.

• Clients reprocessing historical periods should also review the resulting GL output before transmitting journals to downstream accounting or ERP systems.

Who is affected:

• This enhancement applies to clients using FX cash flow hedge accounting where an FX hedge relationship is one of the following before the associated equity balance has been fully reclassified:

  • de-designated

  • terminated

  • fully transitioned to fair value

• Hedge relationships where the equity balance is released immediately, or where no deferred equity balance remains after termination, are not affected.

Recommendation:

• We recommend reviewing open or previously terminated FX hedge relationships that retain a deferred equity balance beyond the termination or de-designation date.

• Where applicable, re-run GL Processing for the affected accounting periods and reconcile the resulting equity postings against the termination report before transmitting journals to downstream accounting systems.

• Any manual journals previously used to maintain these deferred balances should also be reviewed and retired where no longer required.

• For further assistance, please contact your Ripple Treasury representative.

Enhancement

RFI-657

Limit Management & Approval: Extended Limit Checking and Approval for Live Deals

Limit checking and multi-level breach approval have been extended to include live deals that have already started but have not yet matured.

This provides broader control over outstanding positions by ensuring that live deals are assessed against applicable limits when they are captured, amended, or submitted.

Previously, limit checking focused on deals starting today or in the future. Deals that had already started but were still outstanding could therefore fall outside the limit check during subsequent capture or amendment activity.

With this enhancement, deals with a maturity or end date of today or later are also included in limit checking.

Where a live deal breaches an applicable limit, it follows the same multi-level approval workflow already used for future-dated deals. Existing approval levels, thresholds, approver groups, and routing rules continue to apply, so no separate approval process is required.

Limit utilisation at the point of approval also reflects both live and future-dated outstanding positions, providing a more complete view of exposure.

Approval and rejection activity continues to be recorded in the existing approval audit trail, with no change to previously recorded approval history.

Matured deals remain outside the scope of limit checking, and existing deals are not automatically reassessed simply because the feature is enabled.

Impact to users:

• This feature is off by default and is controlled by the feature flag TreasuryApprovalRuleFeature.

• It also requires the Treasury Management Multi-level Approval licence.

• Clients who wish to extend limit checking and approval to live deals should contact Ripple Treasury to have TreasuryApprovalRuleFeature enabled for their environment.

• Once enabled, users may see additional limit breach messages and approval requests when capturing, amending, or submitting deals that are already live but have not yet matured.

• Existing limit definitions, approval rules, approver groups, screens, and reporting remain unchanged. Deals already in the portfolio are not reassessed in bulk and will only be evaluated when relevant deal activity occurs.

Who is affected:

• This enhancement applies to clients using:

  • Treasury limit checking

  • Treasury Management Multi-level Approval

  • Live or future-dated deals subject to limit controls

• It applies to deal capture, amendment, submission, and supported interface or import flows.

• Matured deals are not included. Cash account renegotiation continues to follow its existing limit-checking behaviour.

Recommendation:

• Before enabling the feature, we recommend reviewing your current limit utilisation, approval thresholds, and approver groups to ensure they remain appropriate for the broader population of deals that will be checked.

• Clients may also wish to enable the feature for a limited group or environment first to assess the volume of additional approval requests before wider rollout.

• To enable TreasuryApprovalRuleFeature, please contact Ripple Treasury.

• For further assistance, please contact your Ripple Treasury representative.

Enhancement

RFI-407

Market Rate Rollover for FX Forwards in Hedge Accounting

Hedge Accounting has been enhanced to support market rate pre-deliveries and extensions for designated FX forwards.

This allows treasury teams to roll an FX forward at the current market rate while continuing the existing hedge relationship, with the realised rollover amount retained in hedge equity until the hedged item affects earnings.

Previously, designated FX forwards could only be pre-delivered or extended using the original deal rate. A rollover using the current market rate was not supported.

With this enhancement, designated FX forwards can now be pre-delivered or extended at market rate without de-designating and creating a new hedge relationship.

Where the rollover crystallises a realised gain or loss, that amount is incorporated into the hedge equity balance and released in line with the existing treatment of the hedged item.

The Hedge End-of-Period report has also been enhanced with a Cash line in the accounting section to show the realised rollover amount and support reconciliation of the hedge equity balance.

Effectiveness testing continues to operate as before. Realised rollover cash is excluded from the retrospective effectiveness assessment so that the rollover itself does not introduce artificial ineffectiveness.

Partial rollovers and multiple successive rollovers are supported. Rollovers completed using the original deal rate continue to behave as they do today.

Impact to users:

• No new screen or rollover process is required.

• To use market rate rollover, each hedge relationship containing the FX forward must have Adjust for Pre-deliveries & Extensions enabled. If this setting is not enabled for all applicable hedge relationships, the market rate rollover will remain unavailable.

• Users may notice:

  • Realized rollover amount included in the hedge equity balance

  • New Cash line on the Hedge End-of-Period report

  • Corresponding changes to hedge accounting and journal values associated with the rollover

• Existing hedge release schedules continue to apply, and there is no change to FX forward pre-delivery or extension behaviour outside Hedge Accounting.

Who is affected:

• This enhancement applies to clients using cash flow hedge accounting for FX forwards where designated forwards are pre-delivered or extended at market rate.

• The enhancement supports:

  • Full and partial rollover

  • Multiple successive rollovers

  • Continuation of the existing hedge relationship through the rollover

• This release does not extend the same treatment to rollovers performed using a separate FX swap. Existing hedge documentation requirements and equity release schedules also remain unchanged.

Recommendation:

• We recommend reviewing the Adjust for Pre-deliveries & Extensions setting for hedge relationships containing FX forwards that may be rolled at market rate.

• After completing a market rate rollover, review the Hedge End-of-Period report and related accounting journals to confirm that the realised amount is reflected appropriately within the hedge equity balance.

• Where your accounting policy requires additional rollover documentation, continue to complete that documentation in accordance with your organisation's existing processes.

• For further assistance, please contact your Ripple Treasury representative.

Fixed

RFI-449

Enhanced Monthly Accrual and Cashflow Reporting in the Borrow/Invest Statement

The Borrow/Invest Statement has been enhanced to provide clearer monthly principal and interest movements for borrowing and investment positions.

Users can review opening accrual, accrued interest, cash interest settled, and closing accrual across one or more consecutive months, supporting more direct month-end reconciliation without the need for manual recalculation or spreadsheet workarounds.

The Borrow/Invest Statement now provides more consistent accrual and interest-payment reporting across monthly periods.

Opening accruals now reflect the full unpaid interest carried forward from prior periods, including amounts accumulated across multiple coupon periods.

Interest payments are also attributed to the appropriate reporting period. For example, where interest is paid in advance on a period boundary date, the payment is reported in the period that begins on that date.

Accrual calculations now follow the accrual method configured for the relevant instrument type or product in Accrual Settings, and withholding tax accruals follow the same treatment as the associated interest accruals.

Summary and Detail views use consistent opening accrual, interest paid, and closing accrual values. Reporting periods that could previously be omitted in certain maturity or adjusted-payment-date scenarios are also retained.

For best reconciliation results, the Borrow/Invest Statement should now be run from month-end to month-end, rather than from the first day of one month to the first day of the next.

A detailed user manual is available with guidance on configuring the report and reconciling its figures against other Ripple Treasury reports.

Impact to users:

• This feature is off by default and is controlled by the feature flag BorrowInvestStatementOpeningAccrualsFeature.

• Existing clients who wish to use the enhanced reporting behaviour must request production activation through the standard change control process. Please contact Ripple Treasury to arrange enablement.

• Once enabled, users may notice differences in:

  • Opening accrual values

  • Closing accrual values

  • Reporting period in which certain interest payments appear

  • Withholding tax accruals

• These differences reflect the updated monthly reporting treatment.

• Only the Borrow/Invest Statement is affected. Deal setup, cash flows, accounting entries, general ledger postings, valuations, and other reports remain unchanged. Historical data is not restated automatically.

• The feature may be enabled by default for all clients after S10; until then, existing clients should request activation through the standard change control process.

Who is affected:

• This enhancement applies to clients using the Borrow/Invest Statement for borrowing and investment positions with periodic interest payments.

• It is particularly relevant where:

  • Interest remains unpaid across multiple periods

  • Interest is paid in advance

  • Payments fall on reporting-period boundaries

  • Withholding tax accruals are reported

  • Monthly accrual reconciliation is performed using the statement

Recommendation:

• Before enabling the feature, we recommend reviewing the applicable Accrual Settings to confirm that the configured accrual methods align with your accounting and reporting requirements.

• After enablement, run the Borrow/Invest Statement on a month-end to month-end basis and reconcile representative deals across opening accrual, accrued interest, cash interest settled, and closing accrual.

• Refer to the detailed user manual for configuration and reconciliation guidance.

• To enable BorrowInvestStatementOpeningAccrualsFeature in production, please follow the standard change control process and contact Ripple Treasury.

• For further assistance, please contact your Ripple Treasury representative.

Enhancement

159687

Handle Pre-Issue FRN Instruments Gracefully in Securities Report Valuation

Reporting and valuation have been enhanced for securities that have been booked but have not yet reached their issue date.

Securities with a report or valuation date before their issue date are now handled as forward-starting positions, allowing Securities Reports, Mark-to-Market processing, and GL Processing to complete successfully without affecting the valuation of other deals in the portfolio.

Previously, a security that had been booked but was not yet issued could prevent certain valuation-based processes from completing when the selected report date fell before the security's issue date.

With this enhancement, these pre-issue securities are now treated consistently as forward-starting positions.

For reporting dates before the issue date:

• Security is reported using its captured inception values

• Accrued interest is reported as zero

• Market yield and duration are not calculated for the pre-issue period

• Mark-to-Market processing completes without valuation errors

• GL Processing continues for the remaining portfolio without creating a valuation posting for the pre-issue security

Other securities in the same portfolio continue to be valued and reported normally.

Valuation behaviour on and after the security's issue date is unchanged.

Impact to users:

• No action or configuration changes are required.

• Reports that previously could fail because they included a not-yet-issued security will now complete and include the pre-issue position using the appropriate inception values.

• Users may therefore see additional rows in historical or back-dated Securities Reports where pre-issue positions were previously absent because the report did not complete.

• For some pre-issue positions that could previously be valued, market value or premium/discount figures may differ from historical report outputs because the position is now reported using its captured inception values rather than a calculated market price. This affects only dates before the security's issue date.

• Existing deal setup, booking workflows, and valuations on or after the issue date remain unchanged.

Who is affected:

• This enhancement applies to clients using valuation-based processing for fixed-income securities where the report or valuation date can fall before the security's issue date.

• Relevant outputs include:

  • Securities Report

  • Mark-to-Market

  • GL Processing

• The enhancement applies across supported securities including Bonds, Floating Rate Notes, Inflation-Linked Bonds, Asset Backed Securities, and Discount Securities.

• Clients that do not report or value securities before their issue date will see no change.

Recommendation:

• We recommend reviewing historical or back-dated reporting processes that include securities between their booking date and issue date, particularly where manual workarounds were previously used to exclude those positions or adjust the report date.

• Where historical report outputs are compared across periods, note that pre-issue securities may now appear using their captured inception values.

• For further assistance, please contact your Ripple Treasury representative.

Enhancement

RFI-526

Enhanced Bank Guarantee Schedule Management for Trade Finance and Treasury Operations

Guarantee processing has been enhanced to support Custom Schedule maintenance and Maturity Date amendments through import and export files.

A new Guarantee with Custom Schedule option is now available within Deal Import / Export Definitions, allowing users to maintain irregular guarantee schedules in bulk rather than updating each schedule period manually.

This enhancement supports the Financial Letter of Credit use case and also provides broader benefits for clients using Guarantees for other purposes.

Users can now import Custom Schedule changes for an existing confirmed Guarantee, including:

• Schedule dates and payment dates

• Period-specific Base Rates

• Balance Movements, including increases and decreases

• Maturity Date changes

The same definition can also be used to export an existing Guarantee Custom Schedule, making it easier to review the expected file structure and prepare future imports.

Where a Guarantee is not already using a Custom Schedule, the import can enable the schedule automatically and apply the imported changes to the existing deal terms.

Imported rows can add new schedule periods or update existing periods by date. Principal balances continue to be derived from the schedule movements in the same way as when the schedule is maintained on screen.

The import follows the existing Guarantee amendment process, so current validation, approval, maker/checker, and audit controls remain in place.

Impact to users:

• No action is required to enable this enhancement.

• Users can create a new Import / Export Definition under Category: Deals using the Guarantee with Custom Schedule sub-category.

• The feature is intended for maintaining existing confirmed Guarantees. It does not create new Guarantee deals and does not replace the existing Guarantee import used for initial deal creation.

• Imports are validated before an amendment is saved. If schedule data for a Guarantee does not meet the applicable validation requirements, the amendment is not partially applied and the import results identify the failed records.

• Existing Guarantee setup, approval workflows, and manually maintained schedule behaviour remain unchanged.

Who is affected:

• This enhancement applies to clients using Guarantees, including:

  • Financial Letters of Credit requiring irregular or period-specific schedules

  • Bank guarantees used for trade finance

  • Guarantees used for broader non-trade-finance purposes

• It is particularly useful where Guarantee balances or fee rates change over time and schedule maintenance would otherwise require multiple manual amendments.

• The target Guarantee must already exist in Confirmed status before schedule information can be imported.

Recommendation:

• We recommend exporting an existing Guarantee with a Custom Schedule first to confirm the expected file layout and value formats before preparing a new import definition.

• Clients adopting the feature for bulk maintenance should initially test a representative set of Guarantees and confirm the resulting Custom Schedule, derived balances, and approval workflow before broader rollout.

• For further assistance, please contact your Ripple Treasury representative.

Enhancement

RFI-656

Transaction Lifecycle: Enhanced Trading Visibility in Portfolio and Deal Reporting

Trading lifecycle information is now available directly in the Portfolio view and Deal Report, giving users greater visibility into the status of deals routed through an integrated trading portal.

This enhancement makes it easier to monitor trading activity, build operational views, and include trading status information in reporting and downstream analytics without opening individual trade records.

New trading fields are available in existing portfolio and reporting views:

• Trading Status: Shows the current trading status, such as Not Ready, Ready, Sent, Confirmed, Failed, or Executed.

• Trading Status Date: Shows when the trading status last changed.

• Portal Trade Id: Shows the identifier assigned by the trading portal.

• Trading Portal: Available in the Deal Report and identifies the portal used for the trade.

The same fields are also available through the Deal Report data warehouse extract for use in custom reporting and BI tools.

Users can add the new fields to their existing views and saved layouts and include them in standard exports.

The values shown are the same as those recorded on the underlying trade. This enhancement does not change how trading statuses are generated or maintained.

Impact to users:

• This feature is off by default and is controlled by the feature flag TradingPortfolioFeature.

• Clients who wish to make these fields available should contact Ripple Treasury to have the feature enabled for their environment.

• Once enabled, the new fields become available for users to add to their Portfolio and Deal Report layouts. They are not displayed automatically, and existing personal saved layouts are not overwritten.

• The new grid columns are currently display-only and cannot be used for sorting or filtering within the Portfolio view or Deal Report. Clients requiring additional analysis can use standard exports or the Deal Report data warehouse fields.

• No data migration or changes to existing deals, valuations, or reporting processes are required.

Who is affected:

• This enhancement applies to clients using Trading portfolios integrated with a supported trading portal, currently including 360T.

• It is particularly useful for users who want to monitor trading activity across multiple deals or incorporate trading lifecycle information into operational reporting and BI dashboards.

• Deals that have not been routed through a trading portal will show blank trading status fields.

Recommendation:

• We recommend enabling the feature initially for users responsible for trade monitoring, treasury operations, or reporting, and adding the new fields to relevant Portfolio and Deal Report layouts.

• Clients using the Deal Report data warehouse may also wish to incorporate the new trading fields into existing dashboards or operational reports.

• To enable TradingPortfolioFeature, please contact Ripple Treasury.

• For further assistance, please contact your Ripple Treasury representative.

Enhancement

RFI-837

Forward-Looking Recurring Task Schedules for Operational Planning and Reporting

The Tasks module has been enhanced to generate the complete schedule of a recurring task when it is created.

Each scheduled occurrence is now available as an individual task record, giving users visibility of past, current, and future operational activities and making future task information available for reporting and downstream processing where a data warehouse is configured.

Previously, a recurring task was represented by a single current record, with the next occurrence created only after the existing occurrence was completed. Future scheduled activities were therefore available through the recurrence definition, but were not represented as individual task records for operational reporting.

With this enhancement, the complete recurrence schedule is created when the task is saved. Each occurrence has its own scheduled date and retains the relevant task information, including name, description, owner, category, priority, business unit, portfolio, and facility associations.

This provides:

• Complete view of past, current, and future task occurrences

• Independent tracking and completion of each occurrence

• Improved operational planning using the existing Tasks screen

• Forward-looking task data in the reporting data store where the client uses the Ripple Treasury data warehouse

This means future scheduled activities can be used in reporting and downstream processes, such as operational monitoring or notification solutions, without waiting for the preceding task occurrence to be completed.

Non-recurring tasks continue to operate as they do today.

Impact to users:

• This feature is off by default and is controlled by the feature flag TaskRecurringScheduleFeature.

• Clients who wish to use the enhanced recurring schedule should contact Ripple Treasury to have the feature enabled for their environment.

• Once enabled, newly created recurring tasks will generate their full schedule immediately, up to a maximum of 200 occurrences.

• Users should confirm recurrence settings carefully before creating the task, as recurrence configuration cannot currently be changed after the recurring task has been created. If a different schedule is required, a new recurring task should be created.

• Existing recurring tasks are not converted automatically. Tasks created before the feature is enabled will continue to use their existing behaviour unless they are recreated after enablement.

• Completing an occurrence no longer creates the next occurrence, as future occurrences already exist as part of the generated schedule.

Who is affected:

• This enhancement applies to clients using the Tasks module to manage recurring operational activities.

• It is particularly relevant for organisations that want to:

  • Plan and monitor future operational tasks

  • Report on upcoming activities as well as completed activities

  • Analyze recurring workload across owners, business units, portfolios, or facilities

  • Use task data from the data warehouse for further reporting, monitoring, or notification processes

• The enhancement applies to newly created recurring tasks after the feature is enabled. Non-recurring tasks are unaffected.

Recommendation:

• Before enabling the feature, we recommend reviewing your existing recurring task designs and considering how much future schedule visibility is required.

• After enablement, define recurring tasks with appropriate start dates, end dates, and frequencies, keeping each schedule within the 200-occurrence limit.

• Clients using the Ripple Treasury data warehouse may also wish to review existing task reporting and downstream processes to take advantage of future scheduled occurrences now being available as individual records.

• To enable TaskRecurringScheduleFeature, please contact Ripple Treasury.

• For further assistance, please contact your Ripple Treasury representative.

Fixed

162182

Correct Trading Margin for lot-based FRNs priced on Settlement Amount

Trading Margin calculation has been enhanced for Floating Rate Notes (FRNs) captured in lots and priced using the Settlement Amount quotation method.

When this enhancement is enabled, the Trading Margin derived from the entered settlement amount is calculated consistently regardless of the number of lots, providing more accurate deal pricing and related calculations.

Previously, for FRNs captured in multiple lots and priced using Settlement Amount, the derived Trading Margin could increase significantly as the number of lots increased. For larger lot quantities, a valid Trading Margin might not be returned.

With this enhancement, the Trading Margin is calculated consistently from the settlement amount entered and is no longer affected by how the overall deal quantity is divided into lots.

For example, where an FRN is entered at par, the derived Trading Margin will align with the applicable initial margin. For deals priced above or below par, the Trading Margin will adjust appropriately to reflect the settlement amount entered.

This improvement applies when capturing or amending affected FRNs. Existing deal-entry workflows and fields remain unchanged.

Valuation and reporting calculations that were not affected by this behaviour remain unchanged.

Impact to users:

• This feature is off by default and is controlled by the feature flag FRNTradingMarginLotScalingFixFeature.

• Clients who wish to use the corrected Trading Margin calculation should contact Ripple Treasury to have the feature enabled for their environment.

• Existing deals are not automatically recalculated when the feature is enabled. Deals previously saved with an affected Trading Margin will retain their existing stored values until they are recalculated and saved again.

• After enablement, clients should therefore review relevant existing FRNs and recalculate affected deals where appropriate. This will ensure that Trading Margin and related values such as yield, market value, premium or discount, and amortisation are aligned with the settlement amount entered.

Who is affected:

• This enhancement applies to clients who capture or amend Floating Rate Notes where:

  • the instrument is captured in lots

  • the quotation method is Settlement Amount

• FRNs not captured in lots and FRNs priced using other quotation methods are not affected by this change. Other fixed-income instrument types are also unaffected.

Recommendation:

• Clients using lot-based FRNs with Settlement Amount pricing should contact Ripple Treasury to have FRNTradingMarginLotScalingFixFeature enabled.

• Once enabled, we recommend reviewing existing affected deals and recalculating and saving them where appropriate. Ripple Treasury can assist with identifying the population of deals that may require review.

• For further assistance, please contact your Ripple Treasury representative.

Fixed

160598

Preserve custom field values when a Loan/Deposit deal is amended and resubmitted

Loan and Deposit amendments have been enhanced to preserve existing Custom Field values throughout the amendment process.

This helps ensure that deal information remains complete and consistent when amendments are created, saved as drafts, submitted, and reopened, reducing the need for manual re-entry and follow-up checks.

Previously, when certain Loan or Deposit deals were amended, existing Custom Field values could be cleared or reset during the amendment process.

With this enhancement, Custom Field values are now retained throughout the amendment lifecycle. This includes:

• Starting a new amendment

• Saving and reopening a draft amendment

• Submitting and reopening the amended deal

Where a Custom Field has a configured default value, the value already selected on the deal is preserved rather than being reset to the default.

The enhancement applies across supported Custom Field types, including list, text, numeric, date, and yes/no fields.

Historical deal versions retain their existing Custom Field values, and repeated amendments continue to maintain the correct values for each version of the deal.

There are no changes to Custom Field configuration, default behaviour for newly created deals, or the existing Loan and Deposit amendment workflow.

Impact to users:

• No action is required to enable this enhancement.

• Users no longer need to re-enter Custom Field values when amending affected Loan or Deposit deals. Reports and downstream processes that rely on these values will also continue to receive the expected deal information after an amendment.

• Deals amended before this release are not updated automatically. Where Custom Field values were previously cleared or reset, those historical deal versions will retain their existing stored values and may require manual correction or a one-off data update.

• If you believe existing deals may have been affected, Ripple Treasury can assist with reviewing the relevant population.

Who is affected:

• This enhancement applies to clients using Loan and Deposit instruments where Custom Fields are used and the relevant amendment workflow is enabled.

• Clients whose existing amendment process already preserved Custom Field values will see no change in behavior.

Recommendation:

• We recommend confirming that Custom Field values remain populated when creating and submitting Loan or Deposit amendments after the upgrade.

• Clients that rely on Custom Fields for reporting or downstream processes may also wish to review previously amended deals for any historical gaps.

• For further assistance, please contact your Ripple Treasury representative.

Fixed

158132

Fix Term Column Sorting on Portfolio and Reports Screens

Sorting by Term has been improved across the Portfolio and Reports screens.

Users can now sort deals by their actual duration, making it easier to review portfolios from shortest to longest term, identify longer-dated positions, and analyse maturities more efficiently.

Previously, the Term column could be sorted based on the text displayed in the grid rather than the actual length of the deal. This could result in terms such as days, months, and years appearing in an unexpected order.

The Term column now sorts by the underlying deal duration while continuing to display the same familiar values, such as 7d, 9m, or 3.0y.

Ascending and descending sorting now provide a consistent shortest-to-longest or longest-to-shortest view.

The same improvement also applies to other supported grid columns where a formatted or derived value is displayed but sorting should be based on the underlying value.

Existing paging, filtering, saved layouts, grouping, totals, and export functionality continue to operate as before. Saved layouts that already include Term sorting will automatically use the corrected sorting behaviour.

Impact to users:

• No action or configuration changes are required.

• Users who sort by Term will notice that rows are now ordered according to the actual duration of each deal rather than the displayed text.

• Existing Term values and grid layouts remain unchanged. Manual workarounds such as sorting by start or end date, or exporting data for separate term sorting, are no longer required.

Who is affected:

• This enhancement applies to users of the Risk Portfolio and Reports screens who sort or review deals by term.

• It may also improve sorting behavior for other supported columns that display formatted values while relying on an underlying numeric value for ordering.

Recommendation:

• We recommend reviewing any saved layouts that include Term sorting and confirming that the updated ordering aligns with your portfolio review and reporting needs.

• For further assistance, please contact your Ripple Treasury representative.

Fixed

160977

RTE when loading FX dashboard

The FX Dashboard loading experience has been improved to prevent intermittent errors or stalled loading when the dashboard is opened and refreshed.

Users can now enter and refresh the dashboard more reliably, with no impact to existing chart layouts, calculations, settings, or underlying data.

Previously, users could occasionally encounter an error or an indefinitely loading screen when refreshing the FX Dashboard immediately after opening it.

With this enhancement, the Refresh button remains temporarily unavailable while the dashboard completes its initial loading process. Once the required information has loaded, Refresh becomes available as normal.

Refresh also remains unavailable while an existing refresh is in progress, helping prevent overlapping requests.

The same loading protection has also been applied to the Facilities Dashboard.

There are no changes to dashboard calculations, chart content, report parameters, saved layouts, or user preferences.

Impact to users:

• No action or configuration changes are required.

• Users may notice that the Refresh button is briefly unavailable when first opening the FX Dashboard or while a refresh is already running. This is expected behaviour and ensures the dashboard is ready before another refresh can be requested.

• Existing workarounds, such as leaving and reopening the module or reloading the browser after a stalled dashboard, should no longer be required for this scenario.

• Existing dashboard layouts, settings, and data remain unchanged.

Who is affected:

• This enhancement applies to clients using the:

  • FX Dashboard

  • Facilities Dashboard

• It is particularly relevant where users previously experienced intermittent loading errors or stalled dashboard screens when opening or refreshing these dashboards.

Recommendation:

• No changes to normal dashboard usage are required.

• Allow the dashboard to complete its initial loading process before using Refresh. If loading or refresh issues continue after the upgrade, please provide the relevant date, time, and any support information displayed on screen when contacting Ripple Treasury.

• For further assistance, please contact your Ripple Treasury representative.

Fixed

162835

RTE when loading Facilities Dashboard

The Facilities Dashboard loading experience has been improved to prevent intermittent errors or an empty dashboard when users refresh the screen before it has finished loading.

This enhancement provides a more reliable dashboard experience without changing any calculations, layouts, filters, or saved settings.

Previously, users could occasionally encounter a runtime error or an empty No data to display result if Refresh was selected before the Facilities Dashboard had completed loading.

With this enhancement, the Refresh button remains temporarily unavailable while the dashboard finishes loading the information it needs. Once loading is complete, Refresh becomes available as normal.

The dashboard has also been improved so that Refresh reliably becomes available once loading finishes and no longer remains unavailable for the rest of the session.

There are no changes to dashboard calculations, results, filters, layouts, saved preferences, or underlying facility data.

Impact to users:

• No action or configuration changes are required.

• Users may notice that Refresh is briefly unavailable when first opening the Facilities Dashboard. This is expected behaviour and ensures the dashboard is ready before a refresh can be requested.

• The previous workaround of navigating away from the dashboard and returning should no longer be required for this scenario.

• Existing saved layouts, facility setup, report configuration, and historical results remain unchanged.

Who is affected:

• This enhancement applies to clients using the Facilities Dashboard.

• It is particularly relevant for users who previously experienced intermittent loading errors, empty dashboard results, or a Refresh button that remained unavailable after opening the screen.

Recommendation:

• No changes to normal dashboard usage are required.

• Allow the dashboard to complete its initial loading process before using Refresh. If loading or refresh issues continue after the upgrade, please provide the relevant date, time, and any support information displayed on screen when contacting Ripple Treasury.

• For further assistance, please contact your Ripple Treasury representative.

Fixed

162721

User Unification Migration Creates Users with No UserProfileHistory, Making Them Unapprovable

Resolved a sync issue that was preventing the user group change approval flow from completing for some specific settings.

Enhancement

158094

Wells Fargo Payments Connector: Wire, ACH, and Instant Payments (Phase-1 Wired Completed)

Wells Fargo wires now follow the same straight-through workflow, approval controls and audit trail as your other payment banks, with no re-entry in the bank portal and no chasing the bank for confirmation.

Wells Fargo is available as a payment bank for wire payments over a direct API connection. Initiate and approve a Wells Fargo wire in Ripple Treasury and it is sent to the bank by API, with payment status returned automatically. No file transfer or portal upload is involved. ACH and instant payments over the same API connector are planned for a later release.

Enhancement

158359

Support Unix Epoch Date/Time Format in Calculated Date Parameters and Calculated Headers

Calculated Date parameters and calculated headers now support Unix epoch output, so banks requiring epoch-millisecond timestamps can be configured rather than code-changed.

Enhancement

158714

ENH BNYM Payments Connector: Real-Time Payments (RTP)

Time-critical disbursements can settle in seconds from the same screen and approval flow you already use for BNY Mellon wires and ACH, instead of being initiated in the bank portal.

Real-time payments are now available on the BNY Mellon payments API connector, alongside the existing payment types. Payments are released from Ripple Treasury to BNY Mellon on the RTP rail by API, and status is returned automatically.

Enhancement

159262

SCB Connector: Add AES Decryption for HTTP Error Responses (4xx/5xx)

The Standard Chartered connector now decrypts AES-encrypted HTTP error responses, so bank-side failures surface as readable errors instead of ciphertext. Certificate handling simplified to remove per-region Key Vault setup.

Enhancement

159494

Fix Token Cache Key to Prevent Cross-Account Token Sharing

Fewer total API calls to your bank for the same activity, which helps if your bank applies rate limits or charges per call.

API tokens issued by your bank are now reused until they expire, rather than being requested again before they need to be. Tokens are held per company, so companies using the same published connector no longer cause each other's tokens to be re-requested.

Enhancement

160960

FA Bank Signed-Digest: Marketplace Runtime (HMAC-SHA512)

HMAC-SHA512 Signed-Digest request signing implemented in the Marketplace runtime, exposed in CCG configuration and UI, and validated end to end against the First American Trust sandbox. This unblocks an xPressWire / xPressPort connector build, and the signing pattern is generic and reusable for other banks using the same scheme.

Enhancement

160966

RBC Business Banking: Bank Reporting Connector (Balances and Transactions)

Your morning cash position is complete earlier in the day, and the daily routine of downloading files from RBC's portal goes away, along with the risk of it being missed.

RBC Business Banking balances and transactions now flow into Ripple Treasury automatically over a direct API connection, on the same schedule as the rest of your banks, giving both prior-day and current-day positions. There are no files to retrieve or import.

Enhancement

162836

Current-Day (Estimated) Transaction Detail Silently Dropped When the Bank Sends a Blank Reference

The current-day view now accounts for every transaction the bank reports, so you can rely on an intraday position without waiting for the next morning's file.

This applies to API reporting connectors only, for clients using the current-day (Estimated) view where the bank sends transactions without a bank reference number. File-based connectors were not affected. Where a bank reported two or more current-day transactions with no reference on the same account and value date, only one was stored. The others were treated as duplicates and discarded, so the intraday transaction list did not fully explain the intraday balance. The detail did appear the following morning once the prior-day file was processed, and prior-day records were always complete. Transactions with no bank reference are now matched on amount, bank code and sequence rather than on an empty reference.

Enhancement

159096

Date Filter (Adaptive: Range vs Single Date by Layout)

Worksheet View now adapts its date filter to your worksheet — a single date when it's laid out by date, or a start and end date range when it isn't — and adds a Date Type picker for Value, Transaction or Process date. Changing a date or clicking Refresh updates the grid immediately, and amounts display with the correct decimals for their currency. Available under the new Worksheets New menu, switched on per company by the Worksheets_WorksheetsV2Feature flag. The existing Worksheets menu is unchanged.

Enhancement

159102

Basic Worksheet Detail Listing + Server-Side Pagination

You can now click any amount in Worksheet View to open the new Worksheet Detail page and see the individual transactions behind it — actuals, estimates and payments, or forecasts, depending on the cell you clicked. The list loads 15 rows at a time with sorting and a totals row for the full result, and Back returns you to your worksheet exactly as you left it. Available under the new Worksheets New menu, switched on per company by the Worksheets_WorksheetsV2Feature flag. The existing Worksheets menu is unchanged.

Enhancement

159103

Filter the Worksheet Detail Listing

Worksheet Detail can now be filtered by User Code, Account ID, Transaction Amount, CR/DR, Description or Comment, with an All / Selected / Not Selected view and a running selected count. Results and totals update as you type, and Clear Filters resets everything in one click. Available under the new Worksheets New menu, switched on per company by the Worksheets_WorksheetsV2Feature flag. The existing Worksheets menu is unchanged.

Enhancement

159104

View a Transaction (Navigate to Balance View)

Each Worksheet Detail row now has a View action that opens the transaction's full details — actuals and estimates open the new Balance Detail page, while forecasts and payments open the existing viewer. View only appears for transaction types you're permitted to see. Available under the new Worksheets New menu, switched on per company by the Worksheets_WorksheetsV2Feature flag. The existing Worksheets menu is unchanged.

Enhancement

159106

Edit / Clone Transaction via Legacy Bridge

Worksheet Detail rows now offer Edit and Clone, which open the existing transaction screens and bring you back to your worksheet when you're done. Each action only appears when it's allowed for that transaction, and Clone isn't offered for payments — matching how it works today. Available under the new Worksheets New menu, switched on per company by the Worksheets_WorksheetsV2Feature flag. The existing Worksheets menu is unchanged.

Enhancement

161857

Menu V2: Map New-Cash "Worksheets New" and "Balance Explorer New" into Liquidity Management

Added Worksheet New and Balance Explorer New Menu Item into the Menu V2 men items.

Enhancement

Refreshed Ripple Branding

The Forecasting module has a new look. We've updated the visual branding throughout to reflect the new Ripple identity, giving you a more consistent experience across the platform. 

Enhancement

Faster Line Item Management

Adding and removing line items from your forecasting model is now quicker and easier. The new interface streamlines this process, cutting down the time spent on routine model updates. 

Enhancement

Improved Application Reliability

We've integrated New Relic monitoring behind the scenes, allowing us to detect and resolve issues faster — meaning a more stable, reliable experience for you. 

Enhancement

Smarter Onboarding Assistant

The Onboarding Assistant now has improved error handling and clearer error surfacing. When reviewing a file, it's now easier to pinpoint exactly what's wrong, so you can fix issues faster and get up and running with less back-and-forth. 

Enhancement

PYMT-164

pain.001 V9 Payment Format: Core Platform Support

Ripple Treasury's payment platform now supports generating payment instructions in the pain.001.001.09 message format, the latest ISO 20022 standard required under SWIFT's 2026 usage guidelines for cross-border credit transfers.

What this means for you:

• For bank relationships confirmed ready for the new format, your payment files will automatically be generated using the updated ISO 20022 structure, no action required on your part.

• For relationships not yet confirmed, your payments will continue to be generated exactly as they are today, with no disruption to your existing processing.

• This is a phased transition, not a cut-over: both formats will run side by side as each bank relationship is confirmed ready, ensuring your payments continue to be accepted without interruption.

Why it matters:

• This upgrade helps ensure your payment instructions continue to be accepted by receiving banks without rejection as the industry moves to the updated ISO 20022 standard.

Enhancement

PYMT-327

ACK file cleanup fails due to session expiry on long-running jobs, causing infinite reprocessing loop

We identified and fixed an issue where payment acknowledgement (ACK) files from certain large batch jobs were not being cleared from processing after completion. In some cases, this caused the same files to be reprocessed repeatedly rather than being finalized.

What changed: Payment acknowledgement processing now correctly completes and clears files at the end of a job, regardless of how long the job takes to run. This eliminates unnecessary repeat processing and reduces load on the platform.

Impact to you: No action is required. You may notice improved processing reliability for larger ACK file volumes going forward.

Enhancement

85716

Create a calendar center for SOFR and link the SOFR rate sets dates to this new calendar

The SOFR calendar is delivered as a normal holiday center, so it is also available for selection wherever holiday centers are chosen:

• On a deal (Holiday Centers on the deal's schedule/date-roll settings), add SOFR alongside the existing centers if you want the deal's payment and roll dates to avoid Good Friday altogether (they will then roll to the preceding/following business day per the deal's business day convention).

• The calendar itself can be reviewed and maintained in Common Data > Holiday Centers, like any other calendar (for example, to add or amend dates for your own conventions).

Adding it is entirely optional: rate setting already follows the SOFR calendar without it. Use it only when your documentation requires payments not to fall on Good Friday.

Data delivered:

• New SOFR holiday center (country US), seeded with all New York holidays plus Good Friday dates from 2002 to 2070.

• New tenants get the calendar at provisioning; existing tenants get it through the release upgrade script (idempotent — no duplicates if it is re-run).

Impact and actions:

• Existing SOFR overnight deals: re-generate / re-run rate sets to pick up the corrected fixing dates and inherited rates. Payment dates and accrual boundaries are preserved.

• Expect Good Friday to disappear as a rate set date on the Overnight Ratesets tab, and to appear instead as an inherited rate only where it is also a payment date.

Enhancement

156899

Trade Executed Event trigger for trading platform trades

You can now react automatically when a trade has been executed and confirmed on your trading platform (e.g. 360T).

A new event, Trade Executed, is available wherever you already choose events today:

• Scheduled Jobs: Pick "Trade Executed" in the Event list on a job, alongside Add Deal, Approve Deal, Confirm Deal, Submit Deal, and the rest.

• Notifications: Build a notification rule on "Trade Executed" so the right people are emailed the moment a trade comes back executed, the same way Deal Submit notifications work today.

Why it matters:

• No manual step, no waiting. Downstream work (for example, sending the executed deal onward via a deal export) starts as soon as the execution confirmation is processed, instead of on the next scheduled sweep.

• Timely visibility. Operations, middle office, or counterparty-facing teams can be notified per execution, with the deal reference and the time it was executed.

• The right meaning of "confirmed." This event reflects external confirmation from the trading platform. It is separate from Confirm Deal, which reflects your matching or internal approval workflow. You can use both, for different purposes, without them overlapping.

What it supports:

• "Trade Executed" as an event on scheduled jobs and on notification rules.

• Fires when executed trade details (such as counterparty, rate, and settlement date) come back from the trading platform and are successfully applied to the trade.

• Fires once per trade for that execution, so a trade is not processed repeatedly.

• Honors the filter criteria you already set on the job or notification rule (for example counterparty, business unit, portfolio, instrument type), so you can scope the trigger to only the trades you care about.

• Sends an email using a new Trade Executed advice template, which states the deal reference and when the trade was executed. As with other advice emails, you can tailor the template content.

• Applies to live, booked trades in your portfolios.

What it does not do:

• It does not fire on in-between or unsuccessful outcomes. Trades that are only sent to the platform, or that fail or are rejected, do not raise the event. Only a successfully applied execution does.

• It does not fire if the incoming details are rejected by validation. If the executed trade details cannot be applied to the trade, no event is raised — review the intake results in that case.

• It is not a replacement for Confirm Deal. Internal confirmation/approval workflow is unchanged, and "Trade Executed" does not advance a deal through your internal approval steps.

• An event-triggered job performs the deal-export work configured in that job. If your job also contains other kinds of tasks, those are still handled by the job's normal schedule rather than by this event.

• Proposed / what-if or draft trades are excluded. Only real trades in your books raise the event.

• No backfill. Trades executed before this release will not retroactively raise the event; it applies to executions processed from this release onward.

• Availability depends on your setup. The trading platform capability and the related interface entitlement must be enabled for your organization. If "Trade Executed" does not appear in your Event list, contact Ripple Treasury Support to confirm your configuration.

What you can do now:

1. Decide what should happen on execution. Common choices: automatically export the executed trade to a downstream system (accounting, confirmations, cash forecasting), and/or notify a distribution list.

2. Create or update a scheduled job. On the job, set Event to Trade Executed, then add the export step you want it to run.

3. Narrow the scope with filters. Use the job's existing filter criteria (counterparty, business unit, portfolio, instrument type, and so on) so the trigger only covers the intended trades. Broad filters mean more automatic activity — start narrow.

4. Set up a notification. Add a notification rule on the Trade Executed event, choose recipients, and review the Trade Executed email template wording before going live.

5. Test in a non-production environment first. Bring an executed trade through your normal trading platform intake and confirm the job ran and the email arrived as expected.

6. Review your existing automation for overlap. If you previously used a frequent time-based job to catch executed trades, consider reducing its frequency or retiring it, so the same trade is not handled twice.

7. Tell the affected teams. Anyone who currently checks executed trades manually should know the work is now triggered automatically, and what will still need a human (exceptions, failed intake, rejected trades).

Enhancement

158508

Automatic Deal Update Based on Holiday Changes (Phse 2)

Automatic Deal Update Based on Holiday Changes. Phase 2 — Loans & Deposits With a Custom Schedule (incl. P&I Loan/Deposit).

Overview: Phase 1 introduced automatic re-versioning of Loan/Deposit deals when a holiday calendar changes — but only for deals on a standard schedule. Deals set up with a custom schedule were excluded: in fact, versioning them was blocked altogether with a validation error ("Versioning invalid for custom schedule / must be amended"), and someone had to open each deal and move the affected dates by hand before it could be versioned. Phase 2 removes that limitation.

Loan/Deposit and P&I Loan/Deposit deals with a custom schedule can now be versioned when schedule dates fall on a non-business day — the dates are adjusted automatically and versioning proceeds, the same way it already works for IR Swap and FRN deals. Everything described in Phase 1 — how the scheduled job detects holiday changes, the portfolios you scope it to, and the run summary — continues to apply unchanged. Phase 2 simply widens the set of deals it can handle.

What This Feature Does: Allows Loan/Deposit and P&I Loan/Deposit deals with a custom schedule to be versioned after a holiday change, instead of blocking with a validation error. Automatically shifts custom schedule event dates so they fall on a business day, using the deal's own day adjustment convention. Automatically shifts custom schedule payment dates so they fall on a business day, using the deal's own payment day adjustment convention. Honors all holiday centers linked to the deal — an adjusted date must be a business day in every one of them. Respects the convention you have configured (for example, Modified Following moves the date forward, or back if moving forward would cross into the next month). Extends the scheduled Auto Version Deals job to custom-schedule Loan/Deposit deals, so they are now picked up automatically alongside standard-schedule deals.

What It Supports:

• Deal types: Loan/Deposit and P&I Loan/Deposit (Credit Foncier) deals using a custom schedule.

• Manual versioning: available for both deal types from the screen.

• Automatic (scheduled) versioning: available for Loan/Deposit custom-schedule deals via the Auto Version Deals job.

• Dates from the version start date onward: only custom schedule dates on or after the version start date are adjusted.

• History preserved: custom schedule entries dated before the version start date are left exactly as they are.

No unnecessary versions: if the adjustment does not actually change any date, the deal is recognized as unchanged and no duplicate version is created.

Everything else unchanged: deals without a custom schedule, and all Phase 1 behavior, work exactly as before. All Phase 1 eligibility rules still apply to the scheduled job (Confirmed or Partially Settled, live deals only, not yet matured, only deals using the affected holiday calendar, and only within the portfolios you select).

What It Does Not Support (Please Note): P&I Loan/Deposit is not in the scheduled job yet — these deals benefit from the automatic date adjustment, but must be versioned manually. Only Loan/Deposit is covered by the Auto Version Deals job in this release. No other deal types — Bond, NCD, ABS, swaps, FX and other instruments remain out of scope and must still be versioned manually.

ABS in particular continues to validate and block when a custom schedule date is not a business day. Dates only — the enhancement adjusts custom schedule event and payment dates. It does not otherwise change how a custom schedule is built. Earlier dates untouched — dates before the version start date are never adjusted, even if they fall on a holiday. No real-time updates — as in Phase 1, changes are applied on the next scheduled run (or when you version manually), not the moment a holiday is changed. Not enabled by default — the enhancement must be switched on for your environment. Until it is, versioning of custom-schedule Loan/Deposit deals behaves exactly as it does today.

These items are planned for future iterations: bringing P&I Loan/Deposit into the scheduled job, and extending automated versioning to further deal types.

What You Can Do:

• Enable it: Ask your Ripple Treasury representative or administrator to switch on the Phase 2 enhancement for your environment, and confirm your "Auto Version Deals" scheduled task and its portfolio scope are already set up from Phase 1.

• Check your deal setup: Review the day adjustment / payment day adjustment conventions and holiday centers on your Loan/Deposit and P&I Loan/Deposit deals — these now determine where adjusted dates land, so accurate setup gives accurate results.

• Validate before you rely on it: Version a few representative custom-schedule deals in a non-production environment and confirm the adjusted event and payment dates are what you expect.

• Retire the manual workaround: Any internal procedure that says "amend the custom schedule dates before versioning" can be simplified once the enhancement is on.

• Version P&I deals manually: Keep P&I Loan/Deposit deals out of your automated-versioning expectations for now.

• Review the results: After each scheduled run, check the summary for how many deals were versioned, skipped, or failed.

• Follow up on failures: Review any failed deals and re-version them manually, or contact support.

• Handle other deal types: For deal types not yet supported, continue to version manually after holiday changes.

Enhancement

159322

Query Exported GL Journals by Deal

GL Processing can now retrieve all exported GL journals for a deal across any date range, ignoring the filters that previously kept them hidden — and when a close-out is blocked by GL journals, the error message now tells you how many entries are blocking it, their earliest dates and their accounting sources, so you know exactly what to look for.

How it worked before this enhancement: Exported GL journals could only be reached indirectly, through the normal GL Processing views, and several restrictions worked against you at the same time: You had to know the right posting period. Exported journals only appeared if the Accounting Period / Custom period you selected happened to cover their journal date, and the period start date was treated as exclusive — so entries on the boundary date did not appear.

Every other filter also had to match. Accounting Source, Accounting Event, Posting Type, Category, Deal Type, Product, Currency, Counterparty, Business Unit, Account Code and so on were all applied to exported journals too. Any filter that did not match the original posting silently hid the entry. Older journals were effectively out of reach. For historical postings — especially in closed periods, or where the original mapping/configuration had since changed — there was no combination of filters that reliably brought the entries back on screen. The close-out error gave you nothing to go on. Attempting a back-dated close-out returned only: "Close-Out Date must be after all existing GL Journal Entries." No count, no dates, no source. Users had to guess which period and source held the blocking entries, try view after view, or raise a support ticket — and the entries they were hunting were often exactly the exported ones they could not query.

Net effect: users knew journals were blocking their close-out, but could neither see them nor unwind them without help.

How the enhancement works:

• New Posting Period option: Exported Journals. In Accounting > GL Processing, with mapping type Deals, Posting Period now offers Exported Journals. You provide three inputs: Period Start, Period End and Deal ID (all three required). The query returns every exported GL journal for that deal with a journal date in the range, inclusive of both dates. It deliberately ignores all other filters — Accounting Source, Accounting Event, Posting Type, Category, Deal Type, Product, Currency, Counterparty, Business Unit, Account Code. Only the GL Chart of Accounts, the deal and the date range apply. Results are shown as the journals were actually posted (the stored account codes and descriptions), not recalculated, so what you see is what went to the ERP. The entries can be unwound from this view, which is what releases the close-out. Because the filters are bypassed, entries that were previously impossible to bring on screen — old postings, closed periods, journals whose mapping has since changed — are now retrievable in a single query.

• Close-out error message now names what is blocking you. When GL journals prevent a close-out, the pop-up now includes: the number of blocking journal entries; the earliest journal date(s) — up to three, so you can see how far back the problem goes; the accounting source(s) involved (Cash Flows, Accruals, Valuations, Hedge Accounting, Reclass); the next step: go to Accounting > GL Processing, select the listed source(s), and unwind those entries. The validation rule itself has not changed — the same entries block the close-out as before. What changed is that you are now told what they are.

What this lets you achieve: Complete a back-dated or historical close-out without raising a support ticket — identify the blocking journals from the message, retrieve them, unwind them, close out. Audit what was actually exported for a deal over any period, in one query, without reverse-engineering filter combinations. Investigate GL discrepancies between Ripple Treasury and the ERP for a specific deal and date range. Clean up historical postings left behind by configuration or mapping changes.

What it supports: Mapping type Deals only. One deal at a time, within one GL Chart of Accounts. Any date range, including closed and historical periods. Reviewing and unwinding the retrieved exported journals. The enhanced close-out message for all accounting sources, on full and partial close-outs, including journals on related (child) deals.

What it does not do: It is not a portfolio-wide query. A Deal ID is mandatory; there is no "all deals" option, and it is unavailable for mapping types other than Deals. It does not un-export or reverse anything in your ERP. Unwinding removes the entries in Ripple Treasury; any correction on the ERP side remains a separate, manual process you must coordinate. It does not change close-out rules. Nothing that was blocked before is allowed now. The message is informational, not a link. It names the screen and sources; you navigate and filter yourself. The message does not list every entry. You get the total count and at most the three earliest dates — amounts, GL accounts and individual references are reviewed in GL Processing. No advance warning. The detail appears when you attempt the close-out, not as a pre-check on the deal. Other filters are ignored, not respected. In the Exported Journals view you cannot narrow results by source or account code — that is the point of the option, but expect a broader result set than the standard views. No existing data is changed by this release, and behavior when nothing is blocking a close-out is unchanged (no GL message appears).

Recommended user actions:

• Go to Accounting > GL Processing, select the named source(s) with a period covering the earliest date, and review the blocking entries. If they are not visible there, they are already exported: set mapping type Deals, Posting Period Exported Journals, enter the Deal ID and a Period Start/End covering the dates from the message.

• Confirm with your accounting team before unwinding anything already reported to the ERP, then unwind the blocking entries.

Availability: Available on release with no configuration required. If your organization prefers the previous behavior, it can be switched off on request — in that case both the Exported Journals posting period and the detailed close-out message are hidden.

Enhancement

159326

Limit Management & Approval — Single Transaction limits: "All Counterparties" Catch-All Limits

This release is a direct continuation of the "Limit Management & Approval — Single Transaction limits" enhancement, which introduced an amount threshold alongside the existing term-to-maturity threshold on the Single Transaction limit (previously labeled "Maturity") and routed breaching deals into your existing multi-level approval workflow. That enhancement still required a limit record for each counterparty you wanted to govern.

This release removes that constraint in two connected ways: A catch-all limit row. You can now define a single "All Counterparties" row that applies to any counterparty without its own specific limit record — a universal default threshold, instead of one row per counterparty. Complete coverage at breach checking, including deals with no counterparty. Every deal is now included in the check against a catch-all limit, regardless of its counterparty or counterparty group — and, importantly, deals submitted with the counterparty field left blank are now checked too, where previously they escaped limit checking entirely. For cumulative (Counterparty Group) limits, a limit configured against "All Counterparty Group" now accumulates exposure from deals in every group, including blank-counterparty deals.

Together these close the two remaining gaps in limit coverage: counterparties you never set a limit for, and deals with no counterparty at all.

Availability: As with the Single Transaction limits enhancement, these capabilities apply only when the Multi-Approval license and the associated feature flag are turned on. If they are not enabled, limits continue to behave exactly as they do in the current production version — the "All Counterparties" option does not appear and legacy behavior is preserved.

Key Functions of This Enhancement:

• Configure an "All Counterparties" catch-all row. When creating a limit record, "All Counterparties" is now available in the Counterparty selector. The row supports the same fields as a specific counterparty row: Effective Date — when the catch-all row starts being applied. Limit Type — e.g. Fixed Term and Amount; leaving it Undefined (or Unlimited) keeps the row inactive without deleting it. Limit Currency and Limit Amount — the amount threshold. Term — the term-to-maturity threshold, entered as a tenor exactly as today. Allow Override — Multi-level Approval or Dashboard Only, behaving identically to a specific counterparty row. Only one "All Counterparties" row is permitted per Limit Type; the option is disabled once one exists. The row appears in the Limits grid with "All Counterparties" in the Counterparty column and is visually distinguished from specific counterparty rows, consistent with the existing All Counterparty treatment on other Limit Set screens.

• Automatic evaluation with no precedence between rows. When a deal is submitted, it is evaluated against the limits for its specific counterparty or counterparty group (if any) and the applicable "All Counterparties" / "All Counterparty Group" limits — at the same time, with no precedence between them. A deal can therefore breach a specific row, the catch-all row, or both.

• Deals with no counterparty are now checked. A deal submitted with a blank or missing counterparty — and therefore no counterparty group — is now included in the check against catch-all limits, rather than being skipped. It is also included in the accumulated exposure of "All Counterparty Group" cumulative limits.

• Cumulative exposure across every counterparty group. Where a cumulative (Counterparty Group) limit is configured against "All Counterparty Group", exposure accumulates from deals in all groups — including groups created after the limit was set up, and blank-counterparty deals — giving a single total-exposure ceiling for the organization. Exposure continues to be measured using the reporting-currency-converted amounts already used today; the calculation basis is unchanged.

• Unchanged breach messaging and approval routing. Breaches raise the standard breach message and notification, with "All Counterparties" shown in place of a counterparty code, for example: Limit Set 'Global Credit Limits', 'Total Group Exposure': the Deal Exposure of USD 25,000,000 exceeds the Limit of USD 20,000,000 by USD 5,000,000. Breaching deals are routed into your existing multi-level approval workflow, using the approval levels, approvers and escalation rules already configured. No new or separate approval process is introduced. Where Allow Override permits it, the breach is presented as an overridable warning; where it does not, the deal is blocked from submission. If one deal breaches several applicable limits, all the corresponding breaches are raised so the approver sees the full picture.

What This Feature Supports:

• A single "All Counterparties" catch-all row per Limit Type, with the same fields, validation and grid presentation as a specific counterparty row.

• Cumulative (Counterparty Group) limits configured against "All Counterparty Group", accumulating exposure across every group. Deals for any counterparty or counterparty group, including ones created after the limit was configured.

• Deals with a blank or missing counterparty. Simultaneous evaluation of specific and catch-all limits, with no precedence between them, and multiple breaches from a single deal submission.

• Allow Override on the catch-all row, including Dashboard Only treatment (surfaced for visibility without forcing the deal into the approval workflow).

• Limit Type = Unlimited / Undefined on the catch-all row to switch it off without deleting it, and reverting it to Undefined leaves specific rows intact.

• Effective Date control — a future-dated catch-all row is not applied to today's deals, so the change can be phased in.

• Deletion and end-dating of the catch-all row in the same way as any other limit row.

• Existing breach notifications, breach message template and multi-level approval routing, unchanged.

• Exposure converted into the reporting/limit currency exactly as today.

What This Feature Does Not Do:

• It does not change how exposure or terms are calculated. Only the population of deals included in a catch-all limit has been broadened; conversion, term comparison and message wording are unchanged.

• It does not change your approval rules. Approval levels, approvers and escalation paths remain owned by the existing multi-level approval module.

• It does not give the catch-all row priority over specific rows. The catch-all row never replaces or suppresses a specific counterparty limit — both apply, and each can breach independently. Where both are configured and both are exceeded, expect two breach messages for the same deal.

• It does not allow more than one catch-all row per Limit Type, and the catch-all row cannot carry different thresholds for different subsets of counterparties. Use specific counterparty rows where differentiated thresholds are needed.

• It does not change what the Single Transaction limit governs. A Single Transaction catch-all row still evaluates the one deal being submitted on its own; it does not aggregate across your deal book. Aggregation remains the behavior of Counterparty and Counterparty Group (cumulative) limits.

• It does not re-evaluate history. Checking applies to deals as they are submitted; deals already authorized before the upgrade are not re-opened or re-approved.

• It does not apply without the license and feature flag. If the Multi-Approval license or feature flag is off, the "All Counterparties" option does not appear and limits behave exactly as in current production. No configuration, no check. If no applicable limit exists and no catch-all row is configured — or the Limit Type is left Undefined — the check is skipped and the deal proceeds normally.

What Users Can Do With This Feature:

• Limit administrators / risk managers:

  • Review your Limit Sets and identify where a single "All Counterparties" row would replace, or usefully supplement, many specific counterparty rows.

  • Create the catch-all row: select "All Counterparties" in the Counterparty selector, set the Limit Type, Limit Currency, Limit Amount and/or Term, and save.

  • Size the catch-all threshold deliberately. Far more deals now fall against it — including deals with no counterparty and counterparties you never configured — so a value copied from a single-counterparty row is likely to be much too low.

  • For "All Counterparty Group" cumulative limits, expect exposure to accumulate considerably faster than on a group-specific limit.

  • Use the Effective Date to phase the change in, and set Allow Override to decide up front whether a catch-all breach is an overridable warning, a hard block, or dashboard-only visibility.

  • Decide whether to keep both specific rows and the catch-all row: keep both for a per-counterparty cap and an overall cap; remove redundant rows if only one is needed, to avoid duplicate breach messages.

  • Switch the row off temporarily by setting the Limit Type to Undefined/Unlimited, or end-date/delete it as with any other row.

• Deal entry / dealers:

  • Use Check Limit on the deal entry screen to preview whether a deal would breach a specific or catch-all limit before submitting — no approval workflow is triggered by the preview.

  • Read the on-screen breach message to see which limit and threshold is affected and by how much; more than one message may appear where several limits are breached.

  • Expect deals without a counterparty to be limit-checked now.

  • Enter complete counterparty data wherever possible so breach reporting stays meaningful.

• Approvers:

  • Review breaching deals arriving in the multi-level approval queue, using the breach message — which shows "All Counterparties" where the catch-all row was breached — to understand the reason. Be aware that breaches may now arise from deals not previously seen as limit-relevant: deals with a blank counterparty, and deals for counterparties or groups with no specific limit row.

  • Approve or reject through the existing approval workflow.

Enhancement

160664

External Triggering of Risk Scheduled Jobs (GL Processing and Others)

Risk scheduled jobs can now be started from an external system via CCG/connectivity, without anyone logging into Risk. The driving use case is GL processing: today a user has to log in and start the job by hand, and this removes that step so the ERP can start it on its own schedule. A file-arrival trigger is planned as a follow-up.

Enabling this requires setup on the CCG/connectivity side, which specifies the client, and the Risk job to be triggered. This is separate from any configuration within Risk itself, is managed by the CCG/connectivity team, and is enabled per client on request rather than through self-service configuration.

The same setup can be used for Risk jobs other than GL processing, subject to the scope below.

What this enables:

• The ERP (or another external system) can start a Risk job on its own schedule, without waiting for a person to trigger it in Risk.

• The mechanism is generic and can be configured per client for other Risk jobs, not just GL processing.

• Each triggered run appears in the Risk job run log with its status, timing and log output, exactly as a manually started run does.

How it works, in plain terms:

1. The external system decides when the job should run.

2. CCG/connectivity authenticates to Ripple Treasury with a pre-configured access key and operator identity, and obtains a temporary, secure credential for that operator.

3. CCG asks Risk to run the configured job.

4. Risk validates the request, queues the job, and returns immediately. The job then runs on the Risk job server and its outcome is recorded in the job run log.

Scope and limitations:

• Operator setup. The trigger acts as a Risk operator configured per client in CCG, which must hold the "Run Now" (Run Job Manually) permission. That operator's permission applies at the operator level, not to a single job — it can trigger any job in the client's Risk tenant — so it should be set up as a dedicated service identity used only for this integration, not a person's day-to-day login.

• No parameters are passed by the call. The trigger identifies the job and nothing else. The job runs with the parameters saved on its definition in Risk, so any job used with this integration must be configured to run correctly, unattended, at any time it may be called. Jobs that need a per-run input — for example a specific GL processing "as at" date — are not supported by this integration; they must be configured to derive that input themselves.

• Fire and forget, and rejections are not signalled as failures. Risk queues the job and responds immediately; it does not wait for the job to finish and returns no result to the external system. Success or failure of the run is visible in the Risk job run log, not in the response to the caller.

  • A follow-up release is planned to let Risk notify CCG of a job's status, closing this gap.

• Job state. A request is rejected if the job is deactivated, or if the same job is already queued or running. Overlapping runs of the same job cannot occur; overlapping runs of different jobs affecting the same data (for example two GL processing jobs on one GL Chart of Accounts) are not prevented, so client schedules should be spaced accordingly.

• Trigger frequency. There is no rate limiting on the trigger, and no queue pile-up for a single job: while a job is queued or running, further triggers for that job are declined rather than stacked. The practical guidance is therefore to set the external schedule to comfortably exceed the job's normal run time, so that a trigger is not routinely arriving while the previous run is still in progress and being discarded. There is no enforced minimum interval.

• Configuration accuracy matters. If the CCG configuration names a job that does not exist in Risk, the call is accepted but nothing runs. Configuration should be verified against the Risk job run log at go-live for each client.

• Audit attribution. Every run is recorded in the Risk job run log. The log records the job, status, timing and output — it does not currently record that the run was started externally, or which operator or external system started it; an externally triggered run is indistinguishable from a manual "Run Now". Attribution of externally triggered runs is planned.

• One operator identity per client, for now. All runs triggered for a client are attributed to a single shared operator identity configured in CCG, rather than to the person or system that caused the run. Whether each client/ERP should have a distinct identity is a decision still to be made.

Fixed

155674

Guarantee Maturity Date/Term fields locked during renegotiation when Product assigned with Custom Schedule

When a user opened a new renegotiation on a Bank Guarantee deal, the fields on the Details tab were greyed out and could not be changed — most importantly the Maturity Date and Term. The maturity row on the Custom Schedule tab was locked as well.

Because of this, users could not extend or shorten the maturity of an existing guarantee through the normal renegotiation workflow. A client reported it when trying to move a guarantee's maturity date to a later date and finding every field on the renegotiation read-only.

The problem only appeared for guarantees that had both:

• Product assigned to the deal (for example a letter-of-credit product template)

• Custom Schedule turned on

Guarantees without a Product, or without a Custom Schedule, were not affected.

Root cause:

• Guarantee deal capture decides which fields can be edited based on the stage of the deal (new deal, amendment, renegotiation) and on how the assigned Product is configured.

• The rule that keeps key economic fields editable during an amendment/renegotiation was only applied when no Product was assigned. As soon as a Product was attached to the guarantee, that rule was skipped — and with Custom Schedule switched on, no other rule allowed the Maturity Date or Term to be edited. The result was a renegotiation screen where nothing could be changed, even though the workflow was designed to allow exactly that.

• The "keep it editable during renegotiation" allowance and the "Product controls the fields" allowance did not overlap, leaving a gap for Product + Custom Schedule guarantees.

What has been fixed:

• Guarantee renegotiations now keep the schedule-driving fields open for editing when the deal uses a Custom Schedule, whether or not a Product is assigned:

Scenarios:

• Product assigned + Custom Schedule on, new renegotiation: Maturity Date and Term editable

• No Product + Custom Schedule on, new renegotiation: Editable (unchanged)

• Product assigned, no Custom Schedule: Product configuration decides (unchanged)

• Guarantee outside of a renegotiation/amendment (for example, saved, live deal): Fields locked as per workflow (unchanged)

Workflow after the fix, for an affected guarantee:

1. Open the guarantee and create a new renegotiation.

2. On the Details tab, update the Maturity Date and/or Term as required.

3. The Custom Schedule tab's maturity event follows the new date, so the cash-flow/expiry schedule reflects the renegotiated terms.

4. Save and progress the renegotiation through the usual approval and workflow steps.

Nothing changes in how the fields are entered, validated, or approved — only whether they are open for editing in this specific situation.

Impact to you:

• No action required. The fix is delivered with the release, applies to all tenants, and needs no configuration, feature switch, or data change.

• Guarantee maturity extensions and reductions can now be completed by the business user in the standard renegotiation workflow, instead of needing a support request or a manual workaround (such as terminating and re-entering the guarantee).

• No change to existing guarantees or history. Previously saved deals, schedules, accounting and reporting figures are untouched; the change only affects what can be edited on a renegotiation going forward.

• No change to permissions, validation rules or approvals. Existing controls over who may amend a guarantee and how a renegotiation is authorised continue to apply, and standard date validations still prevent invalid maturity dates.

• No behaviour change for guarantees that are not on a Custom Schedule — for those deals the assigned Product configuration continues to determine which fields are editable, exactly as before.

Fixed

158340

Fix Cumulative Dollar Offset Retrospective Test for Fair Value Hedges (CapitalValue Exposure)

For Fair Value Hedge relationships that measure the hedged exposure on a Capital Value basis and use the Cumulative Dollar Offset method for retrospective effectiveness testing, the test result was overstated — often by a very large margin.

What users saw:

• The Valuation section of the hedge showed the correct cumulative change in fair value for the exposure (for example, -24K).

• The Testing section of the same hedge used a completely different figure for that exposure (for example, 4.975M) — the exposure's full market value instead of its change in value.

• The resulting offset ratio landed far outside the 80%–125% effectiveness range (percentages in the thousands), so the hedge was reported as failing the retrospective test even though the hedge and the exposure were, in economic terms, moving in step with each other.

Because retrospective test results drive hedge accounting outcomes, this could lead to unnecessary investigation, manual overrides, or de-designation decisions being considered for hedges that were in fact effective.

The Cumulative Dollar Offset test compares how much the hedge changed in value against how much the hedged exposure changed in value, both measured cumulatively from hedge inception.

For Capital Value exposures, an adjustment intended to align the exposure's cash balance with its value at inception was being applied in a way that cancelled out the "since inception" part of the calculation. The result was that the test used the exposure's total current market value as the denominator, rather than the cumulative change in that value since inception.

Two consequences followed:

• The denominator was typically many times larger than it should have been, so the offset ratio was wildly inflated.

• The Testing section disagreed with the Valuation section of the very same hedge, which is what customers noticed first.

Only this specific combination was affected: Fair Value Hedge + Capital Value exposure + Cumulative Dollar Offset retrospective test.

What has been fixed:

• The Cumulative Dollar Offset retrospective test for Fair Value Hedges now measures the hedged exposure using the cumulative change in fair value since inception, consistent with the figure already shown in the hedge's Valuation section.

• Pass/fail outcomes are now correct. A hedge whose exposure and hedging instrument move proportionally (for example, exposure +20,000 against hedge -20,000) now returns a ratio of approximately 100% and passes the retrospective test.

• The Hedge End-of-Period Report now displays the corrected cumulative change values and the corrected test result percentage, so the Testing and Valuation sections agree.

• Genuine cash movements on the exposure (for example, coupons or amortizing principal) continue to be reflected in the calculation — only the incorrect adjustment was removed.

• Existing safeguards are unchanged: where the cumulative change in the exposure is zero, the system continues to handle it gracefully rather than producing an error.

Deliberately unchanged:

• Fair Value Hedges using the default Par Value exposure basis — results are identical to before.

• Regression Analysis and any other retrospective test method — results are identical to before.

• Prospective testing, hedge valuations, and journal entries are not altered by this change.

Impact to you:

• Nothing changes automatically. The corrected calculation is delivered as an opt-in setting that is switched off by default, so no client's existing results, reports, or period-end numbers change until the setting is deliberately enabled for their environment. This allows each client to review the impact before adopting it.

When the setting is enabled:

• Cumulative Dollar Offset ratio (Fair Value / Capital Value hedges): Based on the cumulative change in fair value since inception; ~100% for a well-matched hedge

• Retrospective test outcome: Passes when the hedge is genuinely effective

• Hedge End-of-Period Report: Testing and Valuation sections agree

• Par Value exposures / Regression Analysis: No change

What you should expect and do:

• Affected hedges may move from Fail to Pass on the retrospective test in the first period after the setting is enabled, and the reported effectiveness percentage will change materially (from an inflated figure to a realistic one).

• Review any manual overrides, notes, or de-designation decisions previously made on the basis of an incorrect failure — these may no longer be warranted.

• Hedge End-of-Period Reports produced before the setting is enabled will retain the old figures; reports produced afterwards will show corrected figures. Where prior-period reports have been filed or circulated, plan how the restated results should be communicated internally.

• No changes to data entry, hedge setup, or the day-to-day workflow are required. Existing hedge relationships do not need to be re-created or re-designated.

No workflow or screen changes were introduced — the same screens, reports, and process steps are used exactly as before; only the calculated values and the pass/fail outcome are corrected.

To enable, contact the Ripple Treasury team, who will switch the setting on for your environment once you have reviewed the expected impact on your affected hedge relationships.

Fixed

157666

Fix Date Column Filtering in Select Exposures and Hedges Grid

When building or editing a Hedge Relationship, users open the Exposures & Hedges tab and click Add to bring up the Select Exposures & Hedges window, which lists all eligible deals to choose from. Filtering that list by a date column — such as Deal Date or Settle Date — always returned an empty list. This happened with every filter option ("is equal to", "is after", "is before", "is after or equal to", date ranges, and so on), and regardless of which date was entered. The item count would drop to zero even though the list clearly contained deals within the requested date range.

The list of deals in this window was being displayed with its dates treated as plain text rather than as actual calendar dates. Because of that, when a user asked for something like "Deal Date is after 5/1/2025", the screen was comparing a date value against text that it did not recognize as a date. No row could ever satisfy the comparison, so the grid legitimately reported "no matching items" — even though matching deals were present in the list.

Date values in the Select Exposures & Hedges list are now recognized as real dates, so the column filters behave as expected: Deal Date and Settle Date filters now return correct results instead of an empty list. All date filter operators work — is equal to, is not equal to, is after, is after or equal to, is before, is before or equal to. Combined date conditions work — for example "Deal Date is after 1/1/2025 and Deal Date is before 6/1/2025" using AND/OR logic. Clearing a date filter restores the full list, and the item counter again shows the complete set (for example, back to "843 of 843 Items"). Existing filters on non-date columns are unchanged, as are sorting, grouping, and selection behavior. There is no change to how users work — no new screens, no new settings, no configuration or feature switch to enable. The filters simply work the way they were always intended to.

Fixed

161108

Split-Frequency Rateset Dates Not Aligned to the Payment Schedule's First Roll

What was the issue: On a floating Loan/Deposit deal where the Reset Frequency is different from the payment Frequency (a "split-frequency" deal — for example quarterly payments with monthly rate resets), the rate reset dates shown on the Ratesets tab did not line up with the deal's payment schedule. Instead of starting from the payment schedule's

First Roll date, the reset dates were counted forward from the Start Date, so they landed on the wrong day of the month.

The Roll Day you entered was only respected from the second reset onwards. Example — Start 10-Jul-2026, Maturity 15-Jul-2027, Frequency Quarterly, Reset Frequency Monthly, First Roll 15-Jul-2026, Roll Day 15, Modified Following, Sydney: rateset dates before the fix were 10-Jul, 10-Aug, 15-Sep, 15-Oct, …; after the fix they are 10-Jul, 15-Jul, 17-Aug (15-Aug is a Saturday), 15-Sep, 15-Oct, ….

Two problems followed from this: Reset dates did not match payment dates. The reset schedule looked inconsistent with the interest payment schedule on the same deal. Interest could be silently lost. Because the first reset period (10-Jul to 10-Aug) crossed the 15-Jul payment date, it could not be attached to any payment period, so it was dropped when events were generated — with no warning or error.

In the example above, 31 days of interest simply disappeared from the deal's accruals and cash flows.

Root cause: The reset schedule was built independently of the payment schedule. The system calculated the first reset date as "Start Date plus one reset period" and ignored the payment schedule's First Roll date, Roll Day and Force End of Month settings when the two frequencies differed. Every later reset date was then derived from that incorrect first date.

What has been fixed: The first rate reset date is now anchored on the payment schedule's First Roll date and worked backwards using the reset frequency, so the reset schedule always sits inside the payment schedule. The deal's Roll Day and Force End of Month settings are now applied to reset dates from the very first reset, not just from the second one onwards. Day Adjustment and Holiday Centers are applied consistently, so a reset falling on a weekend or holiday is moved as expected (e.g. 15-Aug-2026 to 17-Aug-2026 with Modified Following / Sydney).

Reset dates behave the same way when the deal is saved and when the Ratesets tab is refreshed, and when a deal is amended (e.g. maturity extended) the newly generated reset dates follow the same, aligned pattern while existing ratesets and rates are left untouched. Because every reset period now sits within a single payment period, no interest period is dropped during event generation — the generated interest events cover the full life of the deal. Impact to clients.

What improves: Split-frequency Loan/Deposit deals show reset dates that match the payment schedule and the entered Roll Day / First Roll, so the Ratesets tab is now consistent with what the deal terms say. Interest accrual and interest events are complete: the gap that previously caused missing interest days on the first period no longer occurs, so accruals, valuations and cash flows for these deals are accurate. End-of-month deals (Force End of Month) now generate resets on month-ends anchored to the payment first roll.

What does not change: Deals where the Reset Frequency equals the payment Frequency behave exactly as before. Deals where the resets are less frequent than payments (e.g. monthly payments with quarterly resets) behave as before, following the payment dates. Cash Account deals are unaffected. If the split-frequency capability is not enabled for your environment, Reset Frequency remains locked to the payment frequency and behavior is unchanged. No screen layout, field or workflow step changes — nothing new to learn, and no configuration required from users.

Action required: Existing split-frequency Loan/Deposit deals created before this release keep their previously generated reset dates until the deal is next saved or amended, at which point the corrected dates are generated. Clients who have such deals should review them and, where the interest schedule matters, re-save or amend the deal so the corrected reset dates and interest events are produced. New rateset rows created this way need their rates entered as usual before submitting.

Enhancement

160536

Long Term Fix for Incident INC- (Bank Account Linkage)

Resolved an issue that was causing where some users were unable to generate SSI due to syncing failures caused by missing field settings.

Enhancement

159451

Add Cursor-Based Pagination Mode to Marketplace HTTP Request Component

Our connector framework now handles cursor-based pagination, meaning we can retrieve complete transaction history from banks whose APIs return data in pages rather than a single response.

What it means for you: more banks, and more complete data from them. This is what allows the RBC connector to deliver full transaction history rather than only the most recent page — and it shortens the runway for every future connector we build on an API of this type.

Enhancement

160182

BCB Payments Ltd Payments Connector — Payments API: Internal Transfers and Wires

New payments connector for BCB Payments Ltd, supporting internal transfers and wires. Payments are released from Ripple Treasury straight to BCB, and payment status flows back automatically.

What it means for you: BCB joins your straight-through payment workflow. Initiate and approve in Ripple Treasury, and see confirmed status in Ripple Treasury — no portal re-entry, no chasing the bank for confirmation.

Enhancement

160526

PNC: Add Internal Account Transfers API: Payments

Move money between your own PNC accounts directly from Ripple Treasury. Internal account-to-account transfers now run through the existing PNC payments connector, so there's no new connector to set up, no new credentials to obtain, and no separate bank onboarding project.

If you already use PNC payments in Ripple Treasury, this capability is available to you on upgrade.

What it means for you: internal funding and concentration transfers stop being a portal task. Fewer logins, fewer manual entries, and a single audit trail for every PNC payment type you run.

Enhancement

160966

RBC Business Banking: Bank Reporting Connector (Balances and Transactions)

New reporting connector for RBC Business Banking. Balances and transactions flow automatically into Ripple Treasury, giving RBC clients prior-day and current-day cash positions without anyone downloading files from RBC's portal.

What it means for you: RBC balances land in your cash position on the same schedule as the rest of your banks. Your morning position is complete earlier in the day, and the daily download-and-import routine goes away — along with the risk of it being missed.

Fixed

161041

MT940 :61: Parser Zeroes Transaction Amounts for All Currencies Except EUR and CHF (EBICS Ruby API)

MT940 statement import via EBICS — transaction amounts.

Applies to: clients importing MT940 statements through the EBICS connector in currencies whose ISO code does not end in R or F — including AED, PLN and USD.

Other MT940 connections are not affected. Transaction amounts on affected MT940 imports were recorded as 0.00. Statement-level balances were correct and unaffected. This is resolved in this release.

Action required: affected statements must be re-imported after upgrade to restore correct transaction detail. Your Ripple Treasury contact will reach out directly to confirm the date range in scope and coordinate the re-import.

Enhancement

162085

Create a new node "Cost of Funds" as a reference basis

A new reference basis called Cost of Funds has been added for AUD. This can be used as a rate for internal funding and in the ALM module.

Enhancement

133385

GT Market Data: Add China One-year Loan Prime Rate (LPR)

China one year and five year Loan Prime Rate tickers added to market data and the basis has been added to CNY. 

Enhancement

161084

7am spot rate tickers added to Refinitiv market data

New 7am FX spot tickers added to market data. A range of currencies vs USD, EUR and GBP.

Enhancement

161085

USD/MXN DOB Fixing

Added two new USDMXN central bank fixings to market data.

Enhancement

LQTY-91

Add Balance Explorer New navigation option behind a feature flag

After turning on the feature flag, you will see a link to the Balance Explorer New page to the right of the legacy balance Explorer Page link.

Enhancement

158690

CRI: Recoserver.exe memory leak enhancement implementation

Added check to AutoReconcile for request termination when the command thread is running. A tTermination request now alerts the memory process that there is no need to continue processing. This addition facilitates the termination request.

Enhancement

New Bank Delta report

A new report highlighting differences between bank balances and the closing sheet, removing the need for a custom report and letting admins check for differences quickly.

Enhancement

Manage business units, banks, and bank accounts directly in Forecasting

Entities can now be edited within Forecasting instead of only via the API. Once you make a change, the API stops overwriting that item, so your customizations stick.

Enhancement

API can now load into historic actuals

The API can load data into historic and submitted actuals.

Enhancement

Per-upload error limit raised

Following the multi-error upload change, the per-upload error limit has been raised from 500 to 1,000 so large files can be debugged in fewer passes.

Enhancement

Faster, more responsive Smart Ledger on large data sets

Performance improvements to Smart Ledger.

Enhancement

158835

Password Reset screen: Update to Username field

This is to update the label from Username to User ID and to remove trailing and leading spaces on the User ID text box on the Request Password Reset screen.

Enhancement

158844

Password Reset screen: Login screen update Username label

This is to update the label and placeholder text from Username to User ID on the Password Reset Login screen.

Enhancement

158846

Password Reset screen: Manage Users and Groups tab updates on email and user ID fields

This is to update the handling and validation of Email and User ID fields on the Password Reset Manage Users and Groups tab.

Enhancement

158849

Password Reset: Only allow active and suspended users to request password reset

This is to restrict password reset requests to Active and Suspended users only.

Enhancement

158850

Password Reset: Update logic that populates inactivedate column on tprincipals table

This is to update the logic that populates the inactivedate column on the tprincipals table.

Enhancement

158943

Password Reset: Manage Users and Groups tab for suspended and inactive users

This is to update the Manage Users and Groups tab's User List to reflect Suspended and Inactive user status after the changes to tprincipals table's inactivedate column.

Enhancement

159025

Password Reset: Only allow active and suspended users to nominate new password

This is to restrict the Nominate New Password action to Active and Suspended users only.

Enhancement

159027

Password Reset: User tagged as “Cannot Change Password” not allowed to use password reset request

This is to prevent users tagged as "Cannot Change Password" from using the Password Reset Request feature.

Enhancement

159140

Password Reset: Update password token table

This is to update the password token table to support the password reset process.

Enhancement

159510

Password Reset: Implement rate limiting for password reset requests

This is to implement rate limiting to prevent potential abuse by limiting the number of password reset requests that can be made within a defined time period.

Enhancement

110896

Email field is a required field upon user account creation

This is to make the Email Address field on the Manage Users and Groups tab a required field.

Enhancement

110905

Audit Log Tracking for Password Changes

This is to add audit log tracking for password reset-related scenarios.

Enhancement

110906

Email Template for Password Reset Requests

This is to define the email template that is sent to the client for password reset requests.

Enhancement

151045

Password Reset - Request Password Reset

This is to allow the users to trigger a password reset.

Enhancement

151047

Password Reset - Replace "Trouble logging in?" Link on Login Page

This is to replace the "Trouble logging in?" text and link on the Login page with "Forgot Password" text and link that redirects to the Request Password Reset screen.

Enhancement

151060

Password Reset - Create Link

This is to generate a unique temporary link when a user requests a password reset.

Enhancement

151064

Password Reset - Email Password Reset Link

This is to email the password reset link to the user.

Enhancement

151362

Password Reset - Verify Unique Password Reset Link

This is to verify the validity of the password reset link sent to the user (workflow after user clicks the link on the password reset request email).

Enhancement

151363

Password Reset - Nominate New Password

This is to handle saving of the newly nominated password.

Enhancement

156630

Password Reset Nominate New Password - UI

This is to construct the Nominate New Password screen.

Enhancement

161071

SSO - Replace GT Certificate

This is to replace the expired GT SSO Certificate. 

Enhancement

158165

Fix DivideByZeroException in FRN Securities Report when report date is a non-business day near maturity

We fixed a problem that could cause the Securities Report (and the related MTM Report) to fail completely when it was run on a non-business day (a weekend or holiday) and the portfolio contained a Floating Rate Note (FRN) or a similar bond-style security such as an ABS that was about to mature.

With this fix, these reports now complete successfully in that situation, and every instrument in the report is valued as expected.

Previously, a near-maturity FRN valued on a non-business day collapsed into a "zero-length" calculation window, and the report could not recover from it.

Ripple Treasury now sources the appropriate rate directly for that final stretch to maturity and produces a valid valuation for the FRN. The improvement takes effect automatically once the release is applied.

Enhancement

158351

FX accounting for Loan/Deposit instrument

This enhancement lets Ripple Treasury automatically calculate and record foreign exchange (FX) gains and losses on foreign-currency Loan and Deposit instruments, in line with IAS 21 (The Effects of Changes in Foreign Exchange Rates).

When a loan or deposit is denominated in a currency other than your functional (reporting) currency, its value in your books changes as exchange rates move. This feature measures those movements for you and posts the correct accounting entries so your foreign-currency debt is always reported accurately in your functional currency with a clear, auditable record of the rates used.

The calculations use a FIFO (first in, first out) tranche method: each drawdown is tracked as its own tranche at the exchange rate on that date, and settlements are matched against the oldest tranches first.

Key Functions:

• Automatic tranche tracking: Every drawdown on a foreign-currency loan or deposit is recorded as a tranche capturing the amount, the date, and the exchange rate at that time (the cost basis).

• Unrealized FX gain or loss at period-end: During period-end close, outstanding balances are re-valued at the closing exchange rate and the resulting unrealized gain or loss is posted automatically.

• Realized FX gain or loss on settlement: When a loan or deposit is paid down (fully or partially), the realized gain or loss is calculated by matching the payment to the oldest tranches first. Realized entries are posted as non-reversing GL entries.

• Partial settlements handled correctly: If a payment only covers part of a tranche, the remaining balance keeps its original cost basis and only the paid portion generates a realized gain or loss.

• Reversing unrealized entries: Unrealized FX gains and losses are posted as reversing GL entries: they automatically reverse in the next period through the system's standard reversing-entry mechanism, so each period-end reflects the current position without double-counting.

• Exchange-rate sourcing: Rates are drawn from one of two sources: the spot rate from Market Data, or a configured GL FX rate set (selected through GL Mapping).

• Full audit trail and reporting: Every entry clearly separates realized vs. unrealized amounts, shows the exchange rates used and the tranche matching detail, and provides both the foreign-currency and functional-currency amounts for period-over-period reconciliation.

• Safeguards for missing rates: If an exchange rate needed for period-end or settlement is missing, the system alerts you and holds the processing until the rate is supplied, preventing incorrect postings.

What It Supports

• Loan and Deposit (L/D) instruments denominated in a foreign currency.

• Multiple currencies and multiple drawdowns per instrument.

• Unrealized FX gain and loss at each reporting period-end (retranslation at the closing rate).

• Realized FX gain and loss on full or partial settlement, using FIFO matching.

• Automatic reversal of unrealized amounts through the reversing-entry mechanism (unrealized entries reverse in the following period), so they don't overlap with realized amounts recognised on settlement. This is handled by the reversing posting type, not by a separate reversal transaction at settlement time.

• Configurable FX rate source either the spot rate from Market Data, or a GL FX rate set (via GL Mapping).

• Reversing treatment for unrealized FX gains and losses (auto-reversed in the following period), and non-reversing treatment for realized FX gains and losses.

• Detailed reporting and audit trail, including the exchange rates and tranche matches behind every figure.

• Controlled rollout via a feature flag that can be enabled at environment, company, or user level.

What It Doesn't Support:

• Only Loan and Deposit instruments are covered in this release. Other instrument types (for example, bonds, intercompany, cash accounts) are not in scope here.

• Non-reversing treatment isn’t available for unrealized FX gains and losses. Unrealized entries are always posted as reversing entries. Non-reversing applies only to the realized FX gain/loss entries.

• Interest accruals FX gain and loss on foreign-currency debt are outside the scope of this feature.

• If required exchange rates are missing, the related processing is intentionally blocked until rates are provided. This is expected behavior, not an error.

• Because the feature is off by default, no behavior changes until it is enabled. Existing processing continues exactly as today when the flag is disabled.

What You Need to Do

1. Request enablement of the feature. The functionality is gated behind a feature flag and is switched off by default. Ask your administrator to enable it for the appropriate environment, company, or users once you are ready.

2. Confirm your exchange-rate source. Decide and configure which of the two supported rate sources should be used, the spot rate from Market Data, or a GL FX rate set (configured on the GL Mapping), so revaluation and settlement use the intended rates.

3. Check your GL Chart of Accounts and GL Mapping. Make sure the GL accounts for realized and unrealized FX gains and losses exist in the GL Chart of Accounts and are correctly mapped in GL Mapping so entries post to the right places.

4. Ensure exchange rates are loaded. Confirm closing rates are available for your reporting dates and settlement dates before running period-end close or processing settlements. Missing rates will hold processing.

5. Run period-end close as usual. With the feature enabled, unrealized FX gains and losses are generated automatically during the close.

6. Process settlements as usual. Realized FX gains and losses and unrealized reversals are calculated automatically when loans/deposits are paid down.

7. Expect unrealized entries to auto-reverse. Unrealized FX gains and losses post as reversing entries and will reverse in the following period automatically. Plan your reconciliations accordingly.

8. Review the reports and audit trail. Use the realized vs. unrealized breakdown, exchange-rate detail, and tranche matching to validate results and support your reconciliations and audits.

Enhancement

158369

Fix blank Settlement Advice PDF and Missing receipt-direction notifications

The advice was being created before the settlement was fully saved, which left it empty and, for receipts, stopped the email from going out.

The settlement process was reordered so that the Settlement Advice is now built and emailed only after the settlement batch has been fully saved. With the settlement details already in place, the advice document is populated correctly and the email is generated and sent for both payment and receipt settlements.

Enhancement

158478

Trading Execution And Connectivity

You can now send trade instructions to an external trading provider automatically and in real time, straight from the moment a trade is submitted.

Previously, trades destined for a trading platform sat in a queue and were only picked up every few minutes by a scheduled process. This delay made it hard to know whether a trade had actually been sent, and in some cases the same trade could be sent more than once.

With this release, submitting a trade in a designated trading portfolio immediately hands the trade off to your trading provider and gives you a clear, live status showing exactly where the trade is in the dispatch process.

360T is the first provider we've enabled, but the feature is designed as a general capability intended to work across most instrument types and to support additional trading partners over time.

This feature is controlled by the TradingPortfolioFeature flag, which is turned off by default. It is switched on per environment and client as part of the rollout. While the flag is off, none of the behavior below appears and existing workflows are unchanged.

Key Functions

• New trading portfolio type: When creating a portfolio, you can now choose from three types: Actual, Proposed, Trading (new). Any trade submitted inside a Trading portfolio automatically follows the new dispatch workflow. There is nothing extra to switch on or configure per trade. Choosing the portfolio type is all that's needed.

• Clear visibility of portfolio type: The portfolio type is now shown on both the portfolio list and the portfolio detail views, so you always know before moving or submitting a trade whether it will trigger the dispatch workflow. Trading portfolios are clearly distinguishable at a glance.

• Automatic, real-time dispatch on submission: When you submit a trade in a Trading portfolio, the system sends the instruction to the trading provider immediately, not on a delayed batch schedule. You don't need to take any additional action after submitting. A Send to Portal control is also available for the dispatch.

• A clear trade status lifecycle: You can now follow each trade through the dispatch process using a dedicated trading status that updates automatically. The typical happy path is Not Ready > Ready > Sent > Executed (with Confirmed reflecting the provider's acknowledgement along the way, and Failed flagging any problem). Each status change is timestamped and captured in the audit trail, so there is a complete, traceable record of every trade's journey.

  • Not Ready: The trade is on a Trading portfolio but has not yet been submitted and approved. It cannot be sent yet.

  • Ready: The trade has been submitted and approved and is queued for dispatch. The Send to Portal action is enabled.

  • Sent: The instruction has left our platform and been sent to the trading provider; awaiting acknowledgement.

  • Confirmed: The trading provider (360T) acknowledged receipt of the instruction.

  • Failed: The instruction could not be sent or was rejected by the provider.

  • Executed: The confirmed trade details have been imported back from the trading provider onto the trade. This is the final traded and locked state.

• Importing confirmed trade details back onto the trade (new scheduled job task): A new scheduled-job task (Import Instrument Trading Details) brings the confirmed trade details (for example, rate, counterparty, settlement information) back from the trading provider onto the trade in the Risk platform, and then moves the trade's trading status to Executed.

• Key points about functions:

  • This task is configured and run through Scheduled Jobs (like other import and export tasks), so administrators control how often it runs.

  • Once a trade reaches Executed, it is treated as traded and locked. It can no longer be confirmed, unsubmitted, unconfirmed, or re-sent to the portal. The details are only imported once; a second attempt is rejected.

  • The task only runs when the TradingPortfolioFeature flag is enabled; if the flag is off, the import is blocked.

What This Feature Supports

• Automatic dispatch of trades submitted within a Trading-type portfolio.

• Real-time delivery of instructions to the trading provider (no waiting on a batch cycle).

• End-to-end status visibility: Not Ready → Ready → Sent → Confirmed / Failed → Executed.

• Confirmation handling when the provider acknowledges receipt.

• Importing confirmed trade details back onto the trade via a scheduled job, moving it to the final Executed state.

• Full audit trail of every status change (who/what, when, old value, new value).

• 360T as the initial connected trading partner.

• Designed as a general capability intended to extend across most instrument types and to additional trading partners.

• Governed by the TradingPortfolioFeature flag (off by default).

What This Feature Doesn’t Do

• It doesn't change existing portfolio behavior. Actual and Proposed portfolios and their workflows are completely unaffected. If a portfolio is not enabled for the trading workflow, nothing is dispatched and the existing process continues as before.

• It is currently focused on 360T. While built as a general feature, 360T is the only trading partner connected in this release. Other partners (for example, FXall, FX GO, Bloomberg) are not yet live.

• Self-service configuration in Application Settings is not yet available. A dedicated Trading Platform configuration area — where administrators would map instrument types, platforms, and import and export definitions themselves — is planned but not part of this release.

• Advanced event-based automation is still in progress. Additional automation triggers (for example, a configurable Trading Platform Confirmed job event and a dedicated "move new deal" event for precise job triggering) are planned for a future release.

• This is not a pricing, negotiation, or execution venue. The feature dispatches trade instructions and tracks their status; it does not replace the trading provider's own platform functions.

Recommended Actions

• System Administrators and Portfolio Managers:

  • Create or designate a Trading-type portfolio for trades that should be dispatched to 360T.

  • Confirm the trading workflow is enabled for your environment before going live.

• Traders and Portfolio Managers:

  • Before submitting, check the portfolio type so you know whether submission will trigger dispatch.

  • Submit trades in a Trading portfolio as normal. Dispatch happens automatically. Use Send to Portal where applicable.

  • Watch the trade status to confirm progress: Not Ready > Ready (queued) > Sent (left our platform) > Confirmed (acknowledged by 360T) > Executed (confirmed details imported back, trade is locked).

• Operations Users:

  • Use the trade status and audit trail to monitor dispatches and confirmations.

  • If a trade shows Sent but does not progress to Confirmed and Executed within the expected window, investigate and escalate. A confirmation may be outstanding, the import job may not have run, or the trade may be in Failed.

  • Once the Import Instrument Trading Details job runs and a trade reaches Executed, it is locked (no further confirm, unsubmit, or re-send).

  • Read-only users can view portfolio type and status but cannot change them.

Good to Know

• Real-time means immediate. Once you submit in a Trading portfolio, the instruction goes out right away. Double-check trade details before submitting.

• Duplicate protection. The workflow tracks dispatch status so a trade isn't sent multiple times.

• Failed dispatches are visible. If sending or a rejection occurs, the status moves to Failed rather than Sent, so a stuck trade is visible rather than silently lost.

• Executed is final. A trade only becomes Executed after the scheduled Import Instrument Trading Details job imports the confirmed details back from 360T; at that point the trade is locked and cannot be re-sent.

• Feature is off by default. Nothing above is available until the TradingPortfolioFeature flag is enabled for your environment/client.

• Everything is audited. Every status change is recorded with a timestamp for full traceability.

Enhancement

158507

Automatic deal update based on holiday changes Phase 1: Loans and deposits without custom schedule

When a public holiday is added or changed in a holiday calendar, the payment and cash-flow dates of your deals may need to shift so they no longer fall on a non-business day. Until now, this required someone to manually re-version each affected deal.

This feature removes that manual effort. It automatically detects holiday calendar changes, finds the deals affected by them, and creates an updated version of each deal so its schedule reflects the new holiday calendar as a scheduled background process. This helps keep deal schedules accurate and reduces the risk of missed or mis-dated cash flows.

This is Phase 1, covering Loan/Deposit deals on a standard schedule. Phase 2 will extend automated versioning to Loan/Deposit deals with a custom schedule.

Refer to Loan/Deposit: Set Up and Run Automated Deal Versioning for more information.

What This Feature Does

• Monitors the holiday calendar for changes and identifies which holiday centres are affected.

• Identifies the deals impacted by those holiday changes, based on the calendars they use.

• Automatically creates an updated version of each affected deal so its payment and cash-flow dates reflect the revised holiday calendar.

• Runs on a schedule you control, processing deals within the portfolios you choose.

• Produces a clear summary after each run showing how many deals were versioned, skipped, or failed.

Custom-schedule Loans/Deposits are targeted for Phase 2 (coming soon); other deal types will follow in later iterations.

Enhancement

158941

Limit Management and Approval - Single Transaction limits

This release extends the existing Limit Breach Approval Framework with a new capability: Single Transaction limit tracking and approval.

Until now, the Maturity limit performed a simple per-deal check but had no way to configure an amount threshold. With this enhancement you can now define an amount threshold alongside the existing term-to-maturity threshold for an individual deal, and have deals that exceed either threshold automatically routed into your existing multi-level approval workflow, the same workflow already used for other limit breaches.

As part of this change, the limit previously labelled "Maturity" in the Limits screen is now called "Single Transaction" to better reflect what it governs: a single deal, evaluated on its own.

Availability: These enhancements apply only when the Multi-Approval license and the associated feature flag are turned on. If they are not enabled, the Maturity limit continues to behave exactly as it does in the current production version.

Key Functions of This Enhancement

• Configure amount and term thresholds: On a Single Transaction limit record you can now set features. Either an amount or a term threshold (or both) can be configured. At least one is required to activate the limit.

  • Limit Type: choose "Fixed Term and Amount" (or leave it Undefined, which keeps the limit inactive).

  • Limit Currency: the currency the amount threshold is measured in (defaults to your base currency).

  • Limit Amount: the maximum deal value allowed before a breach is raised.

  • Term: the maximum term-to-maturity allowed before a breach is raised. This is the existing Term field and its behavior is unchanged. It is entered as a tenor (a number plus an optional unit), and it supports days, weeks, months and years. For example 90 or 90D (days), 6M (six months), 1Y (one year), 5Y (five years), and even fractional tenors such as 1.5Y. If no unit is entered, the value is treated as days. (The number is up to three digits. That is, up to 999 of the chosen unit.)

  • Allow Override: controls how a breach is handled.

• Automatic breach evaluation at deal submission: When a deal is submitted or when a user clicks Check Limit, the deal is evaluated against the configured thresholds:

  • Amount breach: the deal's exposure is converted into the limit's currency at the prevailing FX rate; if it exceeds the configured Limit Amount, an amount breach is raised.

  • Term breach: the deal's term (based on its maturity date) is compared to the configured Term threshold. The configured tenor (for example, 1Y) is converted internally to a number of days for the comparison; if the deal's term exceeds it, a term breach is raised.

  • A deal is considered in breach if either the amount or the term threshold is exceeded (both can breach at the same time).

• Clear breach messaging: When a breach occurs, the deal entry screen shows a plain-language message identifying which threshold was breached (amount, term, or both) and by how much, so the user understands exactly why the deal needs approval. For term breaches, the deal term, limit term and the overage are expressed in days in the message (regardless of whether you configured the limit as days, months or years).

• Routing into the existing multi-level approval workflow: Breaching deals are automatically directed into your existing multi-level approval process, using the approval levels, approvers, and escalation rules already configured for the applicable limit set. No new or separate approval process is introduced.

• Choice of how a breach is handled with Allow Override: When the license and feature flag are on, the Allow Override option offers two business choices. When the license and feature flag is off, this control keeps its legacy Yes or No behavior.

  • Multi-level Approval: a breaching deal is held and routed into the multi-level approval workflow for review and sign-off before it can go live.

  • Dashboard Only: the breach is surfaced for visibility/monitoring rather than forcing the deal through the approval workflow.

What This Feature Supports

• A new configurable amount threshold, plus the existing term-to-maturity threshold, on the Single Transaction (formerly Maturity) limit.

• Term expressed as a tenor in days, weeks, months or years (for example, 90D, 6M, 1Y, 5Y, 1.5Y), not days only. A plain number with no unit is treated as days.

• Evaluation of a single submitted deal against those thresholds at submission time and via the Check Limit button.

• Currency conversion of the deal exposure into the limit currency using the current FX rate for amount checks.

• Breach detection on either amount or term (or both simultaneously).

• Automatic routing of breaching deals into the existing multi-level approval workflow.

• Clear, user-friendly breach messages explaining what was breached and by how much.

• A Check Limit preview that lets users see the breach result before submitting, without triggering any approval workflow.

• Consistent look, layout, and validation with the existing Counterparty and Counterparty Group limit screens.

What This Feature Doesn't Do

• It doesn't aggregate across your deal book. Unlike the Counterparty limit, the Single Transaction limit evaluates only the one deal being submitted. It doesn't sum up or consider other live deals against the threshold.

• It doesn't change your approval rules. Approval levels, approvers, and escalation paths continue to be owned by the existing multi-level approval module and are unchanged by this feature.

• It doesn't change how the Term threshold is entered. The Term field is the existing tenor field. This release did not alter it. It is not limited to days; the "days" you see in the grid column heading and in breach messages is only the unit used to display and compare terms, not a restriction on what you can enter.

• It doesn't apply without the license and feature flag. If the Multi-Approval license or feature flag is off, the limit behaves exactly as in current production. The new amount fields and multi-level override options don't appear.

• Check Limit doesn't trigger approvals. Clicking Check Limit only previews the result on-screen; a deal only enters the approval workflow when it is actually submitted.

• No configuration, no check. If no Single Transaction limit exists for the deal's counterparty, or the Limit Type is left Undefined, the check is skipped and the deal proceeds normally.

What You Can Do With This Feature

• Limit administrators / risk managers:

  1. Open a Single Transaction limit record and set the Limit Type to Fixed Term and Amount.

  2. Enter the Term as a tenor (for example, 1Y, 6M, 90D) and the Limit Currency and Limit Amount you want to enforce.

  3. Choose how breaches should be handled via Allow Override (Multi-level Approval or Dashboard Only).

  4. Save the record. The Limits grid will reflect the configured type, currency, amount, term, and override choice. (Records with no thresholds continue to show Undefined.)

• Deal entry / dealers:

  1. Use Check Limit on the deal entry screen to preview whether a deal would breach the configured thresholds before submitting.

  2. Read the on-screen breach message to understand which threshold (amount and term) is affected and by how much.

  3. Submit the deal. If it breaches and Multi-level Approval is selected, it is automatically routed for approval rather than going live immediately.

• Approvers:

  1. Review breaching deals that arrive in the multi-level approval queue, using the breach message to understand the reason.

  2. Approve or reject the deal through the existing approval workflow.

Enhancement

160113

Money Market Fund dividend tolerance enhancement

Automatic monthly dividend imports now post correctly for Money Market Fund (MMF) deals that use a non-standard fund type such as MMF Advance. Previously these deals were being blocked by a tolerance error.

Some clients hold Money Market Fund deals set up with a fund type other than the standard MMF (for example, MMF Advance.) The provider's dividend amount legitimately differs from the system's internal estimate.

In one reported case, the affected MMF Advance deals silently missed their monthly dividend.

The automated dividend import now applies the following rules for fund types:

• MMF (Standard): Still applies; no change.

• MMF Advance (Non-standard): Bypassed; imports without the tolerance restriction.

• Equity (Non-standard): Bypassed; imports without the tolerance restriction.

• Crypto (Non-standard): Bypassed; imports without the tolerance restriction.

No action is required. The fix takes effect automatically once the release is deployed. No changes are needed to your provider files or your existing deal setup.

Enhancement

155637

Dynamic principal-based deal fee calculation

Deal fees can now be calculated as a percentage of the linked deal's outstanding balance. Each period's fee amount is worked out from the linked instrument's actual outstanding balance for that period. So as the principal varies over the life of the deal, every period is charged against the balance that genuinely applies to it, rather than a single amount locked in at the time the fee was set up.

This release addresses two long-standing gaps in how deal fees behaved:

• Fees didn't follow the balance. A percentage-based deal fee locked in its amount at deal creation and kept charging that same flat amount for every period. It didn’t update when the linked instrument's balance later changed through repayments, drawdowns, or amendments, so fees could drift away from the deal's actual exposure. With the new fee type, when the linked instrument's balance changes, the fee is updated to reflect the new balance for the affected periods.

• No way to account for a portion of interest separately. Previously a deal's interest followed a single GL treatment, so there was no clean way to carve out part of it and post it to the ledger differently. Because this new fee tracks the outstanding balance the same way interest does, you can now split out a portion of a deal's interest and give it its own GL mappings, recognizing that slice under a different ledger treatment while keeping it tied to the same deal.

Key Functions:

• New Calculation Type: "Percentage of Outstanding Balance" available when setting up a Deal Fee.

• Balance-driven per-period amounts: Each period's fee is calculated from the linked instrument's actual outstanding balance for that period, so the amounts follow the principal up or down as it changes.

• Calculate Using option lets you choose how each period is valued:

  • Closing Balance (default): Uses the balance at the end of the period.

  • Opening Balance: Uses the balance at the start of the period.

• Fee is updated when the balance changes (the key gap this enhancement closes): When the linked deal's balance changes for any reason (repayment, prepayment, drawdown, amendment, or rollover), the fee schedule is updated to reflect the new balance once you save the deal and re-open the fee. Previously the fee stayed fixed and ignored these changes; no manual re-entry is required now.

• Clean split at balance-change dates: Periods are split exactly on the date a balance changes, so no single period mixes two different balances.

• Accurate reporting: The Events tab, Accruals report, Event Diary report, and Deal Confirmation report all show the correct per-period amounts and the balance each amount was based on.

What It Supports:

• The new "Percentage of Outstanding Balance" calculation type is supported when the deal fee is linked to a Letter of Credit. Deal fees in general can be linked to other instrument types too, such as Loan/Deposit, Bond, FRN, Asset-Backed Security, NCD, and Money Market Fund, but for those the balance-tracking calculation type is not available.

• Standard fee settings: Rate (%), frequency (for example, monthly, quarterly, annually), day count convention, day adjustments, holiday centers, arrears and advance, and effective rate amortization all continue to work with the dynamic amounts.

• Multiple fees on the same deal: Only the "Percentage of Outstanding Balance" fees recalculate; other fees on the same deal are left untouched.

• Protection of posted figures: Once a fee event has been posted to the GL, it is never changed. Only future, unposted events are regenerated when the balance changes.

Accounting for a Portion of Interest

If part of the return on a facility needs to be recognized under a different ledger treatment than the main interest, you can:

• Set up a "Percentage of Outstanding Balance" deal fee for that portion.

• Give the fee its own GL mappings different from the mappings on the original deal's interest.

The fee then rises and falls with the balance exactly like the interest does, but its amounts post to the accounts you specify for the fee, letting you treat that slice of interest income differently in the ledger while keeping it tied to the same underlying deal.

What It Doesn't Do

• Existing fees are not changed automatically. This is a new option you choose when configuring a fee. Fees already set up as "Fixed Amount Per Period" or "Percentage of Deal Amount" keep their current behavior and won't start recalculating on their own.

• "Percentage of Deal Amount" remains static. Only the new "Percentage of Outstanding Balance" type tracks the changing balance. If you want dynamic behaviour on an existing fee, you must reconfigure it to the new type.

• The dynamic calculation type is only available with a Letter of Credit. If you select "Percentage of Outstanding Balance" on a deal fee linked to any other instrument type, the system will not allow it (you'll be told it can only be linked to a Letter of Credit). Deal fees on other instruments must use a different calculation type.

• The amount is not manually editable for this fee type. It is derived from the balance, so the Amount field is disabled and shows N/A on the Fees tab. This is expected.

• Already-posted periods are locked. Recalculation only affects future, unposted events; it does not restate history that has already gone to the GL.

• Updates appear after a save and refresh cycle. After a balance change, save the parent deal and navigate away and back to the fee for the new schedule to appear. It isn’t a live, mid-screen update.

• No manual insertion of extra payment rows into the fee's custom schedule. The schedule is driven by the calculation, not hand-edited.

What You Can Do

• Set up a new dynamic fee. When creating a deal fee, choose Calculation Type = Percentage of Outstanding Balance, enter the rate (%) and frequency, and pick Calculate Using = Closing Balance or Opening Balance.

• Convert an existing fee (if you want it to track the balance). Reconfigure it to the new calculation type. Consider doing this on a copy or test deal first to confirm the resulting schedule matches your expectation.

• Review the generated schedule on the Events tab to confirm the per-period amounts and the balance each is based on.

• Validate against reports. Run the Accruals, Event Diary, and Deal Confirmation reports to see the dynamic amounts and confirm they meet your expectations before posting.

• Let repayments and drawdowns flow through. After recording a balance change on the linked deal, save it and revisit the fee to see the updated future amounts.

Enhancement

159469

Configuration Custom Fields by Instruments and Products

You can now control which deals a Deal-level custom field applies to, so the deal's Custom Fields tab and the Deal Confirmation advice show only the fields that are actually relevant to that trade.

• Restrict by instrument type : limit a custom field to specific instrument types (for example, Letter of Credit, Guarantee, Loan, IR Swap, FX Forward).

• Restrict by product : limit a custom field to specific products, a finer level of control layered on top of instrument type.

Products (set up under Common Data > Products) are a more precise grouping than instrument type. For example, a single instrument type like IR Swap may contain several products such as USD 5Y IRS and EUR 10Y IRS. Together these enhancements let you tailor visibility from the broad instrument type right down to the individual product.

The two controls work independently and together: if a custom field has both an instrument-type and a product restriction, the field is shown only when both match the deal.

How Visibility is Controlled

Visibility can now be controlled at two levels, both new in this release:

• Instrument type: Field shows only for selected instrument types

• Product: Field shows only for selected products (finer-grained)

Both are optional and additive. Leaving a level blank means there’s no restriction at that level (applies to all). Product filtering builds on instrument type: the product list on the configuration page is automatically filtered by the instrument types you've selected.

Configuration for Existing Custom Fields

• No change to existing custom fields. Existing custom fields have no instrument-type and no product restriction, which means they continue to be visible for all instrument types and all products, exactly as they behave today. An empty selection always means it applies to all.

• This is fully backward compatible. Existing fields behave exactly as before until an administrator actively adds a restriction.

• What's new for these fields: administrators can now open an existing field and narrow its visibility by selecting specific instrument types and products, where previously neither control existed.

Feature Flags

Each enhancement is delivered behind its own feature flag and must be enabled for your tenant before the corresponding selector and filtering take effect:

• Instrument-type restriction: IsCustomFieldInstrumentTypeRestrictionFeatureEnabled

• Product restriction: IsCustomFieldProductRestrictionFeatureEnabled

The two flags are independent. Because product filtering builds on the instrument-type selection, both flags are typically enabled together for the full experience. If a selector does not appear, confirm the relevant flag is enabled for your tenant and that the field's Field Application is set to Deal.

Where it Applies (Impacted Screens and Reports)

Instrument-type and product filtering are applied in these places:

• Deal Capture screen: Custom Fields tab: only custom fields matching the deal's instrument type and product (or with no restriction) are shown. Empty group headers are hidden. A deal with no product assigned matches only fields that have no product restriction.

• Deal Confirmation advice report: when the tenant setting "Include Deal Custom Fields on Deal Confirmation Advices" is enabled, only the relevant fields for the deal are included.

• Rate-Set Confirmation advice report: when the equivalent tenant setting to include custom fields on rate-set confirmations is enabled, the same instrument-type and product filtering is applied.

Where it Doesn't Apply

• Only Deal-level custom fields are affected (Field Application = "Deal"). Fields with other applications are unchanged.

• All other reports and views are unaffected and continue to show all active Deal-level custom fields — including Deal Listings and Event Diary.

• The confirmation filtering only applies when the corresponding tenant "include custom fields" setting is turned on.

Data Safety

• No data loss when narrowing restrictions. If you remove a product from a field that already has values on deals of that product, a warning is shown; the existing data is retained in the database but hidden from the UI and reports. Re-adding the product makes it visible again.

• Product deactivation: if a product used in a restriction is later deactivated, the restriction is kept. The field won't appear on new deals for that product (it can no longer be assigned), but existing deal data is preserved.

What You Can Do

• System administrators and operations users:

  1. Open Custom Field: New or Edit and set Field Application to "Deal".

  2. Use the new Instrument Type multi-select to limit the field to specific instrument types (leave blank for all).

  3. Use the new Product multi-select to further limit the field to specific products. The product list is automatically filtered by the instrument types you've selected. If no instrument types are restricted, all active products are available. Leave it blank to apply the field to all products (default).

  4. Review existing custom fields and, where helpful, narrow them to the relevant instrument types/products to reduce clutter.

  5. When narrowing restrictions, read the on-screen warning about data that will be hidden (but retained).

• Deal capture users:

  1. Capture deals as usual. The Custom Fields tab now shows only the fields relevant to the deal's instrument type and product, giving a cleaner, more focused list.

  2. Check that Deal Confirmation and Rate-Set Confirmation advices show the correct set of custom fields for the deal.

Enhancement

159689

Letter of credit extension maturity availment

You can now change a letter of credit (LC) expiry (maturity) date directly from the Availment screen, either on its own or at the same time as a drawing. Previously, the LC's expiry date was shown as read-only reference information on this screen, and changing it required a separate amendment transaction.

A New Expiry Date field has been added to the Availment screen. It defaults to the LC's current expiry date (the value shown as Original Expiry Date), so nothing changes unless you deliberately enter a different date.

Why This Helps

Extending (or, where permitted, shortening) an LC’s maturity is now handled as a normal lifecycle event on the Availment screen. This means:

• You no longer need a separate amendment transaction to move the expiry date.

• You can combine a drawing and an expiry-date change into a single event.

• You can record an expiry-date change on its own, with no drawing and no cash movement. This is useful for a straightforward extension.

What it Supports

• Expiry change on its own (no drawing). If you change the New Expiry Date and leave the Availment Amount blank/zero, the event is accepted as a maturity change only. In this case the Availment Amount is not required. It’s treated as a non-cash change with no balance or cash movement.

• Expiry change together with a drawing. Enter both an Availment Amount and a New Expiry Date to record the drawing and the expiry change in one step.

• Extensions and (where valid) shortening. Moving the expiry date forward (an extension) is the typical use. Moving it earlier is allowed only as long as the new date is on or after the Settlement Date.

• Availment Fee still applies. You can still enter an Availment Fee on an expiry-only change (for example, an extension and amendment fee), so a no-drawing change can still carry a fee.

• Full audit trail. The Letter of Credit is updated with the new expiry date (and its term is recalculated), and the change is recorded in the LC's event and history whether or not a drawing accompanied it.

• Maker and checker unchanged. The change (with or without a drawing) goes through the same approval (maker and checker) workflow you use today.

What it Doesn't Support

• No change on a fully drawn LC. If the availment fully draws down the LC, the New Expiry Date field is disabled and cannot be used. Attempting it produces: "Expiry Date cannot be changed on a full availment."

• New expiry can't pre-date the settlement. The New Expiry Date can't be earlier than the Settlement Date. Attempting it produces: "New Expiry Date cannot be earlier than the Settlement Date." (The new date may be equal to the Settlement Date.)

• A zero-amount event still needs a real change. Submitting with no Availment Amount and no actual expiry change (New Expiry Date the same as the current expiry) is still rejected. An availment must either draw an amount or genuinely change the expiry date.

• Field label wording. The new field is labelled New Expiry Date for Letters of Credit (matching the existing Original Expiry Date). Tailoring the wording between "Expiry" and "Maturity" for different LC styles (for example, standby vs. documentary) is not part of this release.

• Availability. This capability is controlled by a feature setting and may need to be switched on for your environment before the New Expiry Date field appears.

What You Can Do

1. Go to New Availment > Trading HSBC > Letter of Credit for the relevant LC.

2. To extend the expiry only: leave Availment Amount blank, set New Expiry Date to the later date, optionally enter an Availment Fee, then submit.

3. To draw and change the expiry together: enter the Availment Amount and the New Expiry Date, then submit.

4. Make sure the New Expiry Date is on or after the Settlement Date, and that the LC is not being fully drawn (the field is unavailable on a full availment).

5. Submit for approval as usual — the change follows your normal maker and checker process, and the updated expiry and the event are recorded against the LC.

Enhancement

Ripple Treasury Platform rebrand

Across the Ripple Treasury Platform, the menu is changed to our Ripple colors and all Ripple Treasury references and logos are replaced with Ripple Treasury.

Enhancement

152541

Transaction assignment rules: Add remainder general ledger (GL) account validation in CreateGL processor

Enhanced the GL processing workflow to validate remainder accounts before execution, preventing errors that could interrupt automated transaction runs.

Enhancement

157733

Implement Worksheet List API endpoints for Liquidity UI

Added API support for the new Liquidity Worksheet List, enabling retrieval, search, filtering, sorting, and management of worksheets.

Enhancement

157734

Build Liquidity Worksheet List page in React UI

Introduced a new Worksheet List page in the Liquidity UI, allowing you to browse, search, filter, sort, and manage their worksheets in a modern interface.

Enhancement

157853

MT940 Plugin: Add SKIP_VOID_ON_CROSS_BATCH option to prevent voiding when multi-sequence statements are processed as separate jobs in reverse order

Added a new configuration option to prevent incorrect balance adjustments when bank statement files with multiple sequences are imported out of order.

Enhancement

157978

Worksheet Clone button to legacy clone setup page

Added a Clone button to the Worksheet List, allowing you to quickly duplicate existing worksheet configurations.

Enhancement

157979

Worksheet Delete button: Delete via GT.Cash API

Added a Delete button to the Worksheet List with a confirmation prompt to safely remove worksheets.

Enhancement

157981

Worksheet Favorite button: Toggle Favorite via API

Added a Favorite toggle to the Worksheet List, allowing users to mark frequently used worksheets for quick access.

Enhancement

158405

Cash Forecasting integration: Add eventType, eventId, createdDate, updatedDate to BankTransaction ById response

Enhanced the Bank Transaction detail view to include event type, event ID, and timestamp information for improved Cash Forecasting integration.

Enhancement

158407

Cash Forecasting integration: Improve token validation reliability

Improved authentication handling in the Cash Forecasting integration to maintain uninterrupted service during routine security credential updates.

Enhancement

158861

Part 1: Add all the RFC 7807 error-handling files based on POC

Added foundational error-handling framework to the Cash API to support consistent, standardized error responses in future updates.

Enhancement

158862

Standardize API exception handling and response format (RFC 7807)

Standardized error response format across the Cash API to provide consistent, structured error messages for all API consumers.

Enhancement

158901

Part 2: Migrate the Worksheet controller to the RFC 7807 standard

Applied the new standardized error response format to the Worksheet API endpoints, delivering clearer and more consistent error messages.

Enhancement

Larger file uploads, now up to 150MB

Most uploads sections have been raised to 150MB as customers continue to ingest larger data volumes.

Enhancement

GT API integration expanded: move from SFTP to automated data flows

Expanded the GT API integration so many clients can move off SFTP uploads to a more flexible, automated flow.

Enhancement

XRP now supported as a currency in Cash Forecasting

XRP is now selectable as a currency in Cash Forecasting.

Enhancement

Uploads now surface multiple errors at once for faster self-debugging

Uploads now show many errors at once so customers self-debug faster.

Enhancement

Performance, stability, and developer experience improvements

This release includes faster sheet page loads and improved query performance on large datasets, rate tables rebuilt in React for a smoother experience, CSV export for line items.

Enhancement

157539

Create Barclays Bank connector for balance and transaction reporting

A new Barclays connector is available for balance and transaction reporting via the Barclays Corporate Banking API, with support across UK and Europe, US, and India regions, authenticating via OAuth 2.0 with JWS and certificate-based security. Enables on-demand balance and transaction retrieval for Barclays customers.

Enhancement

158094

Wells Fargo payments connector: Wire, ACH, and Instant Payments (Phase-1 Wired completed)

A Wells Fargo payments connector has been delivered, with Wire (SWIFT) payments completed in this phase. The connector follows the standard extract and status-update flow architecture and was validated against the Wells Fargo UAT environment, enabling Wells Fargo customers to initiate wire payments directly from Ripple Treasury with status tracking. ACH and Instant Payments are planned for a later phase.

Fixed

117882

Users Unable to release exposure pieces via the release window

This is to fix the functionality of the Release checkbox on the Period Close window Release Review tab to release all related exposure pieces of the selected exposures to the P&L accounting entries.

Enhancement

158754

Insert View permission on User Groups for Treasury Limits permission category

As part of our ongoing enhancements to multilevel deal approvals, we are introducing four-eyes workflow control across all limit modules, including treasury approval rules and limit sets. This gives organizations the option to apply a second layer of oversight to changes within these areas, supporting stronger governance and segregation of duties. Alongside this, we have formalized view access to limit set data so that access can be managed consistently going forward.

Previously, all users could view limit set information without any specific access control in place. With this release, we have introduced a dedicated view permission for limits, allowing access to be governed in a structured way. To preserve continuity, all existing users and user groups have automatically been granted view access to the limits module, in line with how the system behaves today. This means there is no change to what your users can currently see.

In addition, the new four-eyes workflow control is now available across the limit modules. When enabled, this requires a second authorised user to review and approve changes before they take effect, reducing the risk of unintended or unauthorised modifications.

No action is required to maintain existing view access. This has been preserved automatically for all current users and user groups. Day-to-day visibility of limit set data continues exactly as before.

For organizations that wish to activate the new four-eyes workflow control, this is an opt-in capability. Enabling it will introduce an approval step into the relevant limit workflows, so we recommend reviewing how it fits your internal processes before switching it on.

This enhancement applies to clients using the limits functionality, specifically across:

• Treasury approval rules

• Limit Sets and Limits

Users interacting with limit-related dashboards, exposure reporting, and deal approval workflows will benefit from the improved access management and optional approval controls.

If you would like to take advantage of the new four-eyes workflow control, we recommend planning the rollout in line with your organization's approval and governance requirements. To enable this control or to discuss how it can be configured for your environment, please reach out to the Ripple treasury team for consultancy.

Enhancement

CAS-4751

Improved application performance

Behind-the-scenes database optimizations mean the application responds faster across the board. By removing redundant processes that were slowing things down, you'll notice a snappier experience.

Enhancement

CAS-4758

Streamlined data administration

Managing your treasury data just got easier. Routine administration tasks that previously required technical support can now be handled directly within the application, reducing delays.

Enhancement

CR-1098

Payment profile refinement

When refining payment profiles in Smart Ledger, you can now select a 12-month look-back period alongside the existing three-month and six-month options. For businesses with longer or more seasonal payment cycles, a full year of history gives you a more representative baseline, leading to payment profiles that better reflect how your counterparties actually behave over time.

Enhancement

Modernized sections of Cash Forecasting UI

A cleaner, more consistent interface across the application, making it easier to navigate, faster to find what you need, and more aligned with the experience users expect from modern financial software.

Enhancement

CAS-4755

Updated sender identity in email communications

Emails from the platform now come from Ripple rather than Ripple Treasury, reflecting our updated brand.

Fixed

157491

CAD.CNH FWD pts missing

This is to fix the Fwd Points behavior on Period Close - moved the fallback logic outside the loop so missing CAD/CNH rows can be created before updating values.

Enhancement

154218

Preserve Roll Day During Renegotiation on Interest Rate Instruments

When submitting a renegotiation on interest rate instruments — including Asset Backed Securities, Loans and Deposits, Floating Rate Notes, and Interest Rate Swaps — the Roll Day field on the Details tab could be unexpectedly changed to End of Month, even when no changes to that field were intended. This release ensures the Roll Day value is preserved exactly as configured whenever a renegotiation is submitted without an explicit change to that field.

Enhancement

154454

Manual interest rate tenor selection for loan and deposit deals

A new Ticker Tenor Type drop-down has been added to the Interest Details panel on Loan and Deposit deal capture. This allows users to manually select the interest rate tenor independently from the payment or rateset frequency.

Enhancement

157028

FX Swap and Multi-Leg Swap instruments: Estimated balance description now includes Deal Group and Other Reference

When multi-leg swap instruments were submitted with Settlement Standing Instructions (SSIs), the estimated balance description generated for child leg cashflows was missing key fields that were correctly populated on the parent leg (most notably, Deal Group and Other Reference). This fix ensures the estimated balance description for child leg cashflows now includes the same complete set of fields as the parent leg.

Enhancement

157064

Floating-rate Loan and Deposit deals sometimes have a contractual interest rate tenor that doesn't align with the payment frequency or rate reset frequency

This enhancement gives users direct control over both the rate tenor and the rate reset frequency at deal capture, eliminating the need for manual rate entry. A new Tenor drop-down allows users to specify which market data tenor the system should use for rate lookups. The existing Rate Reset Frequency field can now also be set independently from the payment frequency.

Enhancement

158366

Multi-level deal breach approval preview release

Ripple Treasury now supports cumulative counterparty group limit monitoring with a structured, multi-level approval process for deals that breach those limits. When a deal is submitted and its cumulative exposure exceeds a configured threshold, the system automatically places the deal in a Pending Approval state and routes it through a configurable approval workflow before it can be confirmed.

Limits can be defined by counterparty group, business unit, and instrument type and product. You can also customize how exposure is measured, applying calculation formulas that reference specific instrument details to produce an accurate and meaningful exposure figure for each limit context.

Previously, limit breach detection and approval in Ripple Treasury operated through Limit Sets, which didn't support sequential, multi-level approval chains. Breach overrides were either permitted outright or flagged for review outside the system.

Treasury operations and dealing teams now see a new Pending Approval status on deals that breach a configured limit. Designated approvers will action these deals from a new Deal Approvals screen, where deals are grouped by approval rule and step. Deals in Pending Approval status are locked for editing until the approval process is resolved.

Activating multi-level deal breach approval requires the existing limit sets to be deactivated. Both features can't operate concurrently in the current preview build. Full integration, allowing both features to run side by side, is targeted for release by end of year.

This is available as a preview release and is not enabled by default. If your organization operates tiered treasury approval policies and you are interested in exploring this capability, or you would like to share your requirements and help shape the full release, reach out to your Ripple Treasury team. We welcome early adopters and are actively incorporating client feedback into the product roadmap.

Refer to:

• Multi-level deal breach approval: Overview

• Multi-level deal breach approval: Configure

Enhancement

155871

Fix EIR deal fee day count convention inheritance from linked deal

Deal fees using effective interest rate (EIR) amortization are linked to a parent deal, such as a bond, loan deposit, or floating rate note. EIRs spread transaction costs over the life of the instrument under IFRS 9. Previously, the amortization calculation used the day count convention configured on the deal fee itself rather than the one defined on the linked parent deal. Because deal fees default to ACT/365F, this meant that fees linked to deals using a different convention, such as 30/360, produced materially incorrect amortization amounts, carrying values, and P&L figures. This release corrects that behavior.

The EIR amortization engine now inherits the day count convention directly from the linked parent deal when calculating amortization schedules for deal fees. This applies to fees linked to bonds, loan deposits, and floating rate notes across all three EIR amortization types. For example, when a parent deal uses 30/360 period day counts, the resulting amortization amounts reflect that convention consistently across the full life of the instrument, producing figures that are materially correct and aligned with the underlying deal's terms.

• Effective rate: Used for deal fees linked to fixed-rate instruments (bonds and loan deposits). Ripple Treasury calculates a single yield that spreads the fee across the deal's life, following the fee's own payment frequency. Amortization amounts are uneven across periods, as the EIR method applies a compounding approach where the outstanding balance changes over time. The day count convention used in these calculations is now inherited from the linked parent deal rather than defaulting to the fee's own setting.

• Effective rate – rate reset: Used for deal fees linked to floating-rate instruments (floating rate notes). The amortization concept is the same as effective rate, but the schedule recalculates each time the reference rate resets on the FRN. The schedule is generated monthly and merged with the FRN's rate reset dates, meaning amounts change both due to the EIR compounding effect and the underlying rate movements. The day count convention used at each calculation step is now inherited from the linked FRN.

• Monthly effective rate: Used where monthly amortization granularity is required, aligned directly to the parent deal's interest coupon structure rather than the fee's own frequency. This type already inherited the day count convention from the parent deal correctly and is unaffected by this change.

• Straight line amortization: Divides the fee evenly across periods and is not affected by day count convention. No change has been made to this type.

Users managing deal fees linked to instruments with a day count convention other than ACT/365F will see changes to their EIR amortization schedules, period day counts, and associated carrying amounts and P&L figures under effective rate and effective rate – rate reset amortization types. These revised figures represent the correct output under IFRS 9. Deal fees linked to ACT/365F parent deals and those using monthly effective rate or straight line amortization are unaffected.

Please contact your Ripple Treasury representative if you have any questions or would like assistance assessing the impact on your portfolio.

Enhancement

155746

BofA payments connector: ACH

Connect your Bank of America CashPro accounts to Ripple Treasury for automated payment processing. Once set up, you can initiate payments directly from Ripple Treasury, including ACH transfers, domestic wires, foreign wires, FX wires, and real-time payments. Ripple Treasury automatically tracks payment status at Bank of America.

Enhancement

Precision invoice forecasting SmartLedger

You can now configure exactly how overdue invoices flow into future forecast periods. Previously, SmartLedger would spread overdue AP and AR amounts across multiple periods, an approach that rarely reflects how your business actually collects or pays. With the new Carry Forward Rules, you define your own schedule: specify the percentage to carry forward and when (for example, 50% to next Tuesday and 50% to next month). Your forecast mirrors your actual payment and collection behaviour, not a default assumption.

Enhancement

Payment profile refinement

When refining payment profiles in SmartLedger, you can now select a 12-month lookback period alongside the existing 3-month and 6-month options. For businesses with longer or more seasonal payment cycles, a full year of history gives you a more representative baseline, leading to payment profiles that better reflect how your counterparties actually behave over time.

Enhancement

Modernized sections of the UI

A cleaner, more consistent interface across the application, making it easier to navigate, faster to find what you need, and more aligned with the experience users expect from modern financial software.

Enhancement

Onboarding UI and UX improvements

Getting up and running with Cash Forecasting is now more intuitive. Clearer guidance and a more streamlined flow means less time figuring out the setup and more time getting value from the platform.

Enhancement

Upgrades to application instrumentation

When something goes wrong or a question comes up, our team can now diagnose and resolve issues faster than before. Improved visibility into how the application is performing means quicker, more informed support so problems get fixed sooner and with less back-and-forth.

Enhancement

151957

ExPayment PACS: Mitigate deadlock issue

We improved the reliability of PACS payment extract jobs, which could previously slow intermittently when running concurrently or under higher load. Payment extract jobs now complete consistently without requiring manual retries, ensuring a smoother, more dependable payment processing experience.

Fixed

152782

DB connection failure: Exception within transport service

We resolved an intermittent issue where the bank connection could fail with a database connection error when looking up company tenant information. Affected workflows will now complete reliably without requiring manual intervention.

Enhancement

153936

Implement clear logs for 'Failed' ExPayment jobs

When a payment job fails, you'll now see plain-language explanations of what went wrong and where in the process the failure occurred. Error messages are organized by processing phase, making it easier to diagnose common issues directly from the job logs or know exactly what to share with Ripple Treasury Support if you need assistance.

Enhancement

154334

Expand View Job permission to all risk jobs

You can now set view permissions on all risk scheduled jobs. The CanViewJob permission gives system administrators granular control over which user groups can see a job's status, logs, and run details across the Job Status and Scheduled Jobs screens. This means you can restrict sensitive job visibility to specific teams while keeping other jobs open to your broader user base, all from the same permission tree you already use to manage user group access. If you are interested in enabling this feature, please reach out to support for enablement.

Enhancement

156498

EBICS Payment Issue fix: A005 and A006

Corrected the EBICS order-level signature version from A005 (PKCS#1 v1.5) to A006 (RSA-PSS) to resolve DS16 payment rejections on XG1 uploads to Deutsche Bank (Bitpanda connector).

Enhancement

153620

Persist HTTP listener credentials when connector is deactivated

HTTP listener credentials (API keys, basic auth) are now preserved when a connector is deactivated and reactivated. Previously, deactivating a connector deleted its client credentials, requiring administrators to reconfigure them with their bank or third-party provider. Credentials now persist through deactivation/reactivation cycles and are only regenerated when explicitly requested. The UI now displays a confirmation dialog when regenerating credentials and shows context-appropriate button labels (Activate vs. Reactivate, Generate vs. Regenerate).

Fixed

155518

Balance-reporting-import: Stale system lock in dbo.SIGNOUT_INFO causes silent import failures - "Skipped due to partner processing in progress"

Fixed an issue where the balance report import pipeline could silently stop processing if a previous import run was interrupted. A stale system lock in the database would cause all subsequent import runs to be skipped with no error surfaced to users, resulting in missing transaction and balance data. The system now detects and clears stale locks automatically, ensuring balance imports resume reliably after unexpected interruptions.

Fixed

152765

Job finalization exceptions are silently swallowed, leaving jobs stuck in "Processing" status

Fixed an issue where jobs could become stuck in "Processing" status after completing execution. When a database error occurred during the job finalization step, the error was silently discarded, leaving the job in an incomplete state with no error logged. Job finalization errors are now properly logged and surfaced, and the retry logic for transient database errors during finalization is now functional. This affects plugin Cash jobs running through the GT Job Runner.

Enhancement

155127

Replace potentially invalid email addresses

As part of the shared mailbox and distribution list migration, we checked the sender email addresses used within the application. When we found a sender email address error, we replaced it with a known valid active shared mailbox and distribution list.

Fixed

157062

Integration fails due to certificate issue

The FXALL certificate used in AFX was replaced to prevent future integration failures.

Fixed

155085

Deal Report: Include capitalized interest events in Live-to-Date Principal Calculation

In deal reports, "Amount" and "Live-to-Date Principal Paid" now includes Capitalized Interest. For deals structured with capitalizing interest, the deal report was understating the principal balance. Capitalized interest events were being excluded from the calculation. This has been corrected for capitalizing deals across Loan & Deposit, Credit Foncier, Bond, FRN, and ABS instrument types.

Enhancement

155198

Custom schedule: Day 1 repayment support for Loan Deposit deals

Duplicate date validation no longer applies to dates equal to the deal's start date. For fixed rate deals, Rate, Margin, and Capitalize Interest fields are automatically disabled on Day 1 repayment dates.

Enhancement

155597

Add floating rate instrument to CCIRS fair value hedge

A floating rate instrument can be added to a fair value hedge with a cross currency swap. The normal hedge accounting methods still apply.

Fixed

155599

Floating-rate instruments: Rate reset schedule correction

Corrects an issue affecting floating-rate instruments configured with an overnight index reference rate, a simple interest method, and a non-daily reset frequency. Rate reset schedules now align fully to the First Roll date as configured on the instrument.

Enhancement

155925

Bank accounts: Correspondent bank details capture

You can now capture and save correspondent bank details directly against a bank account record in Risk. This capability is controlled by a feature flag and must be enabled for your organization before it becomes available.

Enhancement

156058

Facility-linked deal saves: timeout resolved

Previously, you could encounter a timeout error when attempting to save or submit a deal that had an associated facility. The system would fail to complete the save, preventing deal workflow progression. A background process that runs whenever a facility is attached to a deal for Drawdown Exchange Rate processing was executed in full regardless of whether it was applicable to the deal's configuration, causing the operation to time out. This process has been updated to run only where relevant, eliminating the potential timeout. No action is required. The fix is applied automatically. Deal results and calculated values are unaffected: output is identical before and after the change. If you experienced timeouts when saving or submitting facility-linked deals, you should find that these operations now complete successfully. No steps are required on your part. If you continue to experience issues saving or submitting facility-linked deals after this release, please contact your GT representative.

Enhancement

156812

Add new custom report view: Currency Rate Period End and Average

We have introduced a new custom report view: Currency Rate Period End and Average. This report gives treasury and finance teams direct access to both Period End and Monthly Average FX rates for each currency pair within a single consolidated report. This enhancement simplifies month-end and period-close reporting workflows and supports compliance with foreign currency accounting standards, including ASC 830 and IAS 21.

The Currency Rate Period End and Average report is now available as a data source within our reporting framework. For each currency pair and each calendar month, the report delivers two key FX rate types in a single stacked view:

• Period End Rate: The exchange rate recorded on the last business day of the month, typically used for balance sheet translation and monetary item revaluation at month-end close.

• Monthly Average Rate: The average of all daily exchange rates recorded during the month, typically used for income statement translation.

The report includes the following columns: Currency From and Currency To (code and description), FX Rate Scenario, FX Rate Source, FX Rate, Rate Date, Month End Date, Rate Type (Period End or Monthly Average), Last Updated, and Was Calculated. A Currency Pair convenience column is also provided for easy filtering and grouping.

Users performing month-end FX reporting, balance sheet translation, or income statement translation no longer need to manually extract rate data from separate sources or derive averages and period-end values outside the system. Both rate types are now available together in a single, audit-ready report. The report is now available in the Report Designer under Data Sources. No additional setup or configuration is needed on your end.

Enhancement

157129

Letter of Credit: General ledger mappings and processing

This release extends GL Mappings configuration and GL Processing to cover Letter of Credit (LC) deals, enabling treasury accountants to record all LC financial events as balanced, double-entry journal entries directly within the system. Both Import LC and Export LC flows are now supported. Users can now configure GL Mappings for LC deals and generate journal entries across the full range of LC accounting events, including Issuance, Advice, Payment, Receipt, Cancellation, Expiry, and Fee Payment/Receipt. Non-cash events (such as issuance, advice, cancellation, and expiry) and cash events (payments, receipts, and fees) are all included within the Cash Flows accounting source. LC deals also inherit the standard valuation events used across non-derivative instruments. No immediate action is required to benefit from this change. Users wishing to configure GL Mappings for Letter of Credit deals should navigate to the GL Mappings page, select Deal Type: Letter of Credit, and configure debit and credit accounts for the relevant events. Once mappings are saved, GL Processing will generate journal entries for all supported LC events.

Enhancement

157130

Letter of Credit: Import and export definition support

Letter of Credit (LC) deals can now be included in Ripple Treasury Platform's Import and Export Definitions framework. Users can configure import and export definitions specifically for LC instruments, enabling bulk ingestion and extraction of LC deal data via CSV or XML. This release also introduces configurable field mappings tailored to LC data, including LC Type, UCP Version, LC Status, and Expiry Date. With this release, Letter of Credit is available as a selectable sub-category under the Deals category within Import and Export Definitions. When selected, the field mapping configuration displays the full set of LC-relevant fields, correctly excluding fields not applicable to LC instruments (such as interest detail fields and Maturity Date) and including LC-specific fields such as Expiry Date, LC Type, UCP Version, and LC Status. No action is required on existing records. Users wishing to configure LC import or export definitions should navigate to Import and Export Definitions, select Category: Deals and Sub-Category: Letter of Credit, and configure field mappings as required.

Enhancement

OPS-886

Bulk delete for bank matching rules

You can now delete multiple bank matching rules at once, saving significant time for users managing large rule sets. What previously required deleting rules one by one can now be done in a single action, making it faster and easier to keep your matching rules organized.

Enhancement

Cross-solution integration improvements

The transfer of bank transaction data between Liquidity Management and Cash Forecasting has been re-engineered to improve speed, reliability, and resilience. This reduces the risk of delays or failures in your forecast inputs.

Enhancement

CAS-3033

Improved budget allocation for daily models

Budget allocation in daily models now correctly accounts for weekends when they are turned off, distributing values accurately across working days only. This ensures your daily budgets reflect your actual working week without the need for manual adjustments.

Enhancement

Improved system performance at peak times

Processing jobs are now distributed more evenly across all customers, ensuring a consistently fast experience regardless of system load. You'll notice more reliable performance during busy periods, with less risk of delays when the system is under heavy demand.

Enhancement

CAS-3014

More reliable formula engine

Improvements to the formula engine mean complex formula chains behave more consistently and predictably, giving you greater confidence in your forecast calculations.

Enhancement

Digital assets available to view in Ripple Treasury (already live)

You can now connect your digital assets using Ripple account or another custodian. Once your digital asset accounts are connected, Ripple Treasury provides a unified view of fiat (government-issued) currency and digital assets.

The Ripple Treasury Platform lets you manage fiat and digital assets together in one place, including standard treasury reports and cash flow forecasts. This supports using digital assets as a bridge for near real-time international settlement (seconds instead of three to five business days).

Learn more about how you can use digital assets.

Enhancement

146496

Automatic addition of payment template group access to user groups

We have automated permission settings so that when any authorized user creates a new Payment Template Group, that user automatically receives approval to view and edit the newly created Payment Template Group without going through a separate permissions workflow.

Fixed

154658

Hidden user disrupting workflow

Resolved an issue where out of sync system users were causing errors during user group creation and permission setting workflows.

Enhancement

155293

Add placeholders for EUR-AED and EUR-RON to the historical data section

New currency pairs EUR-AED and EUR-RON added to market data.

Enhancement

155383

AUD-CAD volatilities market data

AUD-CAD FX volatilities market data.

Enhancement

155428

Add formulas for MXN currency basis tickers, which use MXN and USD OIS plus forwards

Formulas for synthetic values added for USD-MXN currency basis tickers.

Enhancement

152699

FX dashboard: Performance best and worst scenario analysis for spot and other FX hedges (preview)

This preview release brings multi-instrument hedging visibility into the FX Dashboard.

This results in a single, consolidated view for:

• Range of outcomes a collar program can deliver

• Separate performance of spot execution

• P&L measured against both market conditions and corporate budget expectations

Layout, presentation, and certain details may be refined based on pilot feedback ahead of general availability.

What's New:

• Best-case and worst-case hedging rate range: For portfolios that include FX collars, the dashboard now displays worst-case and best-case effective hedge rates based on collar strike levels, with a range width indicator. Option premiums are factored into both scenarios.

• Spot vs. hedge performance comparison: Spot trades are now broken out into dedicated rows (Spot Term Cashflow, Spot Base Cashflow, and Spot Effective Rate) bucketed by settlement date alongside forward and option data.

• FX gain or loss against target (budget) rate: The dashboard now calculates FX gain or loss against a user-defined target or budget rate in parallel with the existing market rate comparison. Target rates can be configured at portfolio, time-bucket, or currency-pair level and persist across sessions.

• Option premium visibility: Option and collar premiums are surfaced as dedicated rows, so the cost of the options program is explicit and auditable rather than embedded in the effective rate.

This preview is available to those who would like early access. To request access or provide feedback, please contact your account representative or support team.

Enhancement

153703

When selecting Capitalized Interest and Tax, the full gross interest amount is added to the capitalized principal

This release introduces an improvement to how capitalized interest is calculated when tax is applicable on a Loan or Deposit. The system now capitalizes the net interest amount (interest minus tax) to the new principal, rather than the gross amount.

When a Loan or Deposit instrument has both Capitalized Interest and Tax enabled, the system previously added the full gross interest amount to the capitalized principal. With this update, the tax portion is correctly excluded from the capitalization, and only the net amount rolls over into the new principal.

For new deals, no action is required. New Loan and Deposit deals with Capitalized Interest and Tax enabled automatically apply the net calculation going forward.

For existing deals, users will need to resave the deal to apply the updated calculation. We recommend reviewing any active Loan and Deposit instruments where both Capitalized Interest and Tax are enabled and resaving them to ensure the net capitalization logic takes effect. This applies to everyone using the Capitalized Interest feature on Loans or Deposits where tax is also enabled.

Enhancement

154409

Fix apply SSI job EventDate filter excluding same-day financial events

This release improves the Apply Settlement Instructions (SSI) scheduled job to ensure that financial events with same-day or backdated value dates are correctly included in the SSI assignment process.

Previously, certain events, particularly those with a value date falling on the same calendar day as the job execution, could be unintentionally skipped during processing.

With this release, the date comparison has been refined to ensure that all eligible financial events are captured regardless of when during the day the job runs. This is especially relevant for event types such as Principal Drawdowns, which commonly have same-day value dates. This enhancement requires no action or configuration changes. The Apply SSI job will continue to run on its existing schedule, and SSI rules will be applied using your current configuration.

Enhancement

154625

FX option close-out error for PHP

This release addresses two issues encountered during the close-out of FX Options on non-deliverable (NDF) currencies such as PHP.

• Instrument save failure during close-out (constraint violation): A data integrity issue could occur during clone-based workflows, such as close-out, renegotiation, rollover, or version deal, when a prior attempt had failed and left residual data. The system now correctly reconciles internal references during these operations, preventing duplicate key errors on retry.

• Validation failure on NDF FX Option close-out (FixingDate error): When terminating an NDF FX deal early, the system moved the end date to the termination date but did not adjust the Fixing Date accordingly. The system now automatically clamps the Fixing Date to the termination date when applicable.

  • Affected instrument types: FX Forward, FX Option, FX Spot, FX Swap, and FX Collar (NDF variants only).

If your trading activity includes FX Options, FX Collars, or other structured FX products, we recommend turning the currency-level Non-Deliverable setting off and managing the NDF flag at the individual deal level instead.

Enhancement

154843

Fix FX option sell cash settled event suppression logic

This release corrects the settlement event behavior for Sell FX Options with Cash Settled enabled, ensuring that settlement events are accurately generated or suppressed based on whether the option finishes in or out of the money at exercise.

Cash Settled Sell FX Options exercised with a Fixing Rate applied:

• In the money: The system now correctly generates a settlement event with the appropriate non-zero amount, visible in the Events tab and Event Diary.

• Out of the money: The system correctly suppresses the settlement event. Previously, the suppression logic for Sell options did not behave consistently.

Buy FX Options (Cash Settled), Lapsed FX Options, and non-cash-settled (deliverable) FX Options are unaffected by this change.

We recommend that users review any recently exercised Sell FX Options with Cash Settled enabled to confirm that settlement events and associated cashflows are reflecting correctly in the Events tab, Event Diary, and Cashbook.

Enhancement

154923

New public holiday: Issue changing existing deals

A fix has been applied to correct how existing deals are recalculated when a user versions a deal after a new public holiday has been added to the holiday calendar.

Previously, if the new holiday fell on a date where a deal already had a scheduled payment, the system could start the recalculation from the wrong point, resulting in incorrect or missed schedule adjustments.

The system now correctly identifies when a scheduled payment date falls on a newly added holiday and begins the recalculation from that point rather than skipping past it. It also no longer shifts the starting point forward unnecessarily. When a user versions a deal affected by a new holiday, the settlement dates now adjust accurately and consistently, without skipping periods or miscalculating the recalculation window.

This enhancement is relevant to all clients who maintain holiday calendars and have existing deal portfolios with scheduled settlement dates that may be impacted by holiday calendar changes, particularly Interest Rate Swaps, FX Forwards, and other instruments with periodic settlement schedules.

Enhancement

155258

GS MMF rebate Txn integration in import and export definition

This release extends the Goldman Sachs MMF Import integration to support rebate (RIMB) and dividend transaction types. The Goldman Sachs movement files containing these transactions can now be consumed and processed automatically by MMF instruments, removing the need for manual intervention or custom configuration by users.

The Goldman Sachs Movements Import and Export definition has been updated to include the RIMB (Rebate and Reimbursement) transaction type in its data mappings. Previously, the RIMB transaction type was not included in the default data mappings, and the Import and Export definition could not be edited by users to add it. This has now been resolved at the system level.

This enhancement requires no manual configuration. The updated data mapping is applied automatically. This applies to all clients using the Goldman Sachs MMF integration for automated movement file imports, particularly those with MMF funds that generate rebate or dividend transactions.

Fixed

154122

Enforce settlement adjustment tolerance validation on submit

This release strengthens the enforcement of the Settlement Adjustment Tolerance threshold during the settlement submit workflow. The tolerance check now fully prevents submission when an adjusted settlement amount exceeds the configured threshold, ensuring consistent application of your organization's payment control policies.

Previously, when a user adjusted a settlement amount and the adjustment exceeded the configured tolerance, the system would display a warning but still allow the user to proceed with submission.

The system now enforces the tolerance threshold as a hard stop. Settlements with out-of-tolerance adjustments will be blocked at submission until the adjustment is brought within the acceptable range or the tolerance configuration is updated by an authorized user.

This enhancement requires no action or configuration changes from clients. Users who encounter the tolerance block will need to review and correct the adjusted amount before resubmitting.

Enhancement

155684

Letter of credit: End-to-end LC lifecycle management (preview release)

We are pleased to announce the preview release of Letter of Credit management within Ripple Treasury. This release brings the full financial lifecycle of Letters of Credit into the treasury platform, replacing the spreadsheets, offline tracking, and manual reconciliation that most teams rely on today.

What's included in this preview:

• End-to-end LC lifecycle management: Issuance, amendments, drawings, expiries, and cancellations managed within a single workflow, covering both import and export instruments.

• Facility utilization tracking: Real-time visibility into headroom across multiple banking facilities, updated automatically as LC events occur.

• Automated fee accrual: Commitment, issuance, and amendment fees are tracked and accrued against each Letter of Credit.

• Event-based accounting: LC events are classified and posted as they occur rather than during a month-end reconciliation exercise.

  • Amendment and breach approval workflows.

  • Batch operations for high-volume portfolios.

  • Point-in-time historical reporting. Complete audit trail.

This is a preview release. Layout, presentation, and certain details may be refined based on pilot client feedback. This enhancement is additive. existing treasury functionality remains unchanged.

To request access or provide feedback, please contact your account representative or support team.

Enhancement

OPS-1009

Scenario analysis

Treasury teams can now answer executive "what if" questions in real time by modeling best case, base case, and worst case scenarios at the click of a button, replacing hours of spreadsheet work.

Scenarios can be created in three steps: Select Create scenario, right-click to apply changes, and see the impact on your cash position instantly, all without affecting the protected base forecast.

Common treasury scenarios are supported, including downside planning (revenue shortfalls, payment delays), upside planning (accelerated receipts, working capital optimization), strategic events (acquisitions, debt refinancing, dividends), and operational changes (CapEx timing, cost reductions).

Scenarios can be shared across treasury, FP&A, and executive teams with a complete governance and audit trail, and saved to a scenario library for reuse across ongoing planning cycles. The Executive Summary view pins net cash flow and closing balance rows so leadership questions can be answered quickly, including live during board or CFO meetings.

FX rate scenario analysis allows teams to model the impact of currency movements on consolidated cash positions instantly, so questions like "What happens to our cash position if the dollar strengthens 10%?" can be answered in the meeting rather than later.

Enhancement

Performance and platform improvements

Key screens have been migrated to React, aligning with front end modernization and a standardized component library for a more consistent user experience. Improvements to bank file processing also reduce wait times for bank file loading and matching.

Enhancement

CAS-3026

Cross-solution integration improvements

The transfer of bank transaction data between Liquidity Management and Cash Forecasting has been re-engineered to improve speed, reliability, and resilience — reducing the risk of delays or failures in your forecast inputs.

Enhancement

147645

Enhance Payment Status to support part of a transaction number

We've enhanced how Ripple Treasury processes ACH return files to ensure accurate payment matching for organizations that process large transaction volumes. Previously, clients processing more than 9,999,999 ACH transactions potentially could experience mismatches when trace numbers rolled over and duplicates appeared.

With this update, the system now uses a smarter, multi-layered matching approach combining configurable date-range filtering with intelligent disambiguation rules to reliably identify the correct payment record even when trace numbers overlap. Returns will continue to update payment statuses accurately, and Notifications of Change (NOCs) will be stored with the correct return codes and reason fields. This improvement ensures uninterrupted, accurate ACH return processing as your transaction volumes grow.

Enhancement

150138

ExPayment Refactor: User Access Validation

This update strengthens the ExPayment extraction flow by replacing the former external Web API dependency with Ripple Treasury's internal AccessManager service for user access validation. The change improves reliability, reduces external failure points, and adds clearer logging and error handling when access is denied. All functional behavior remains consistent with the previous design, and both unit and integration tests confirm the updated flow. This enhancement delivers a more stable and resilient access control mechanism within the payment extraction process.

Enhancement

150244

ExPayment: Robust null handling and structured logging

This update enhances system stability and observability by adding full null handling safeguards within TransformDataByGFS to prevent runtime exceptions, supported by new unit tests for edge cases. Logging has been upgraded to structured, New Relic compatible output with enriched metadata for clearer diagnostics while ensuring sensitive data is masked. Additional error recovery logic improves handling of unauthorized GFS responses, and overall code quality has been refined for better readability and maintainability.

Fixed

154052

Widgets and dashboards not viewable in Preview

Resolved an issue that was causing the home portal and top menu to not render for specific users in the Preview environment.

Enhancement

152065

Adding unit test case for Balance Import Function app

Unit test coverage has been added for the Balance Import Function app.

Enhancement

152798

Upgrade CCG API to .net 10

The CCG API has been upgraded to .NET 10.

Enhancement

152967

Upgrade Job API to .net 10

The Job API has been upgraded to .NET 10.

Enhancement

152807

The data in application is set up with a name exceeding 35 characters

The Goldman Sachs payment connector now supports alternate name fields for beneficiary name transmission, resolving payment rejections caused by name truncation. When processing payments through the Goldman Sachs API connector, the connector will now check whether an alternate name field is populated on the payment. If present, the alternate name value is used as the beneficiary name sent to Goldman Sachs rather than the primary name field.

Goldman Sachs requires that the beneficiary name on a payment exactly match the name on the destination account, and supports names up to 140 characters. When a beneficiary name exceeded 35 characters, the connector previously truncated the value, causing Goldman Sachs to reject the payment due to a name mismatch.

Enhancement

152971

Secure string list support

Connector administrators can now store and iterate over multiple credentials within a single connector, eliminating the need to create one connector per credential set.

Previously, the only way to manage multiple credentials within a CCG authentication flow was to build a separate connector for each one. For customers with large credential sets this was impractical and difficult to maintain. The secure string list removes that constraint, allowing credential management to scale without multiplying connector configurations.

Enhancement

153519

Balance reporting improvement: Consolidate Authentication and Job Status endpoints

The balance report import process has been updated to use a single, consistent authentication method across all operations, improving reliability and reducing the risk of authentication-related failures.

Enhancement

153858

Add Days Back option to Calculated Date parameter type

Connector administrators can now configure a Days Back option on Calculated Date parameters, allowing jobs to dynamically look back a specified number of days from the current date without any manual intervention.

Fixed

153480

Secure String textbox not obscuring when requested

The Secure String textbox now correctly obscures input when requested, working as expected.

Fixed

153829

Fix OAuth refresh token race condition in scaled-out processing engine

Resolved an OAuth refresh token race condition in the scaled-out processing engine.

Enhancement

153122

Interest rate market data missing or tickers to be added

Two new tickers have been added to SGD for SORA average for 3m and 6m tenors. A new ticker and overnight index has been added to CRC.

Enhancement

153575

Add GBP CPI index

A second inflation index for CPI has been added to GBP.

Enhancement

154445

Create a Custom Index to capture a specific overnight rate

A custom overnight index has been added to AED.

Enhancement

154448

Add USD MXN currency basis tickers

USDMXN currency basis tickers added to Historical Market Data.

Enhancement

154449

rename AEIBOR EIBOR

The name for the AED interbank fixing basis has been corrected.

Enhancement

151501

New cross-platform Ripple Treasury mobile app

Ripple Treasury has launched a redesigned, cross-platform mobile application for iOS and Android, giving corporate treasury teams secure, real-time access to critical workflows from anywhere.

The new app replaces the existing limited iOS-only experience with a modern, enterprise-grade solution that delivers the features treasury professionals need most. Key capabilities in this release include payment approvals (single and batch), a cash visibility dashboard for current and prior-day balances, and push notifications for urgent approval actions.

Security has been built in from the ground up, with enterprise SSO support biometric and face ID authentication for quick, secure payment approvals. Multi-currency support and offline caching ensure the app performs reliably across global teams and varying connectivity conditions.

Built on a modern cross-platform framework and integrated with Ripple Treasury's existing Payments and Cash APIs, the app is designed to scale alongside your organization. Observability and analytics are embedded from day one, enabling continuous performance monitoring and product improvement based on real usage data.

Available on the Apple App Store and Google Play Store.

Fixed

153376

Unnecessary updates happen while loading Customized Rates screen

The fix corrects the behavior and removes the unnecessary processes triggered while loading the Customized Rates screen.

Enhancement

153615

Event Diary end term date default change

The default end term date for Event Diary reporting has been reduced from 50 years to 1 year from the job start date. This change significantly improves job execution performance and reduces server resource consumption for the majority of clients.

Data Warehouse Extract jobs that don't specify an EventDiaryTerm parameter will now default to a 1-year reporting window. If you require a longer date range, you can continue to do so by explicitly setting the EventDiaryTerm parameter in your job configuration.

Enhancement

153647

System sending blank settlement advice via email

Enhanced diagnostic logging has been added to the settlement advice notification process. If a notification fails to generate or send for any reason (such as a missing counterparty contact email address or an unconfigured counterparty settlement instruction) the system will now capture and log detailed information to assist in rapid diagnosis.

This improvement ensures that any future occurrences can be identified, investigated, and resolved with greater speed and confidence.

Enhancement

154624

Parameters for Accruals Report By Period data source in Data Warehouse Extract action

This analysis documents the function and performance impact of each parameter available in the Run Warehouse Extract scheduled job action when the Accruals Report By Period data source is selected.

The Accruals Term (720m) parameter has the highest performance impact as it determines the total time horizon. The Accruals Frequency (monthly) parameter directly multiplies computation; switching to Quarterly is approximately three times faster. The Accruals Start Date (year prior) parameter extends the range backward and has a high performance impact.

Accruals Forecast Events (yes) has a moderate-to-high impact as it triggers full market data valuation workspace loading per batch. Include GL Posted Amount (yes) has a low-to-moderate impact and does not affect the AccruedInterest field. All other parameters have negligible performance impact.

Enhancement

152853

GL processing: Daily valuation journal export

Background:

• Previously, users who required daily valuation journals had to use the Custom posting period with a 1-day date range. While this allowed the journal to be generated and viewed on screen, the export function was restricted to Accounting Period type only, meaning daily journal data could only be extracted by manually copying the grid to the clipboard and pasting into Excel or another application.

• This enhancement introduces a proper Daily valuation frequency as a first-class option within the accounting period framework, bringing daily valuations in line with existing Monthly and Quarterly workflows and enabling full export support.

What's changed:

• A new Daily option is available in the Valuation Accounting Frequency settings, alongside the existing Monthly, Quarterly, and other standard period options.

• Valuation journals generated using the Daily frequency can now be exported directly from the GL Processing screen, consistent with how other accounting period types work.

• The manual Copy Grid workaround is no longer required for daily valuation journal extraction.

Impact:

• Generate a new daily valuation journal:

  • Previously possible via Custom period

  • Now also supported via Daily frequency

• Export a daily valuation journal:

  • Previously required manual copy

  • Now direct export is supported

• Export monthly or quarterly journal:

  • No change

Notes:

• Performance consideration: Daily valuations generate a significantly higher volume of journal entries compared to monthly or quarterly periods. For clients processing large portfolios, this may result in longer processing and report generation times. It is recommended to scope export date ranges appropriately.

• No data migration is required as part of this change.

• Existing Custom period functionality remains available and is unchanged.

For questions or assistance configuring the daily valuation frequency, please contact support.

Fixed

153648

Extension error message

A defect has been resolved that caused an error when submitting a second partial extension or pre-delivery on an FX Forward deal where the same Deal Date was used as a previous extension or pre-delivery, and the deal had custom Settlement Instructions (SSIs) assigned.

The extension and pre-delivery submission logic now correctly handles the case where the same Deal Date is reused across multiple partial operations on the same FX Forward deal. Custom Settlement Instructions on the parent deal version are preserved as expected during this workflow. The interim workaround of using a different Deal Date is no longer required. This fix applies to both FX Forward Extensions and Pre-deliveries.

Fixed

154003

Deals: Submits > Error on new submits, Object ref not set to an instance of an object

A defect has been resolved that caused an error when submitting new deals of types IRS, FX, and CCIRS. Users encountered an Object reference not set to an instance of an object error during the deal submission workflow under certain market data conditions.

A defect in the Exposure Calculation service has been corrected so that expression evaluation will only proceed when all required data (including market values) is confirmed to be available. Deal submission for IRS, FX, and CCIRS deal types now works reliably at any time of day, regardless of whether market data download jobs have completed. The interim workaround of submitting after 11am NZ time is no longer required.

Enhancement

152268

Agentic AI feature toggle for Risk: Application Settings

Administrators can now control access to Agentic AI capabilities within the Risk module directly from Application Settings. A new Agentic AI for Risk toggle allows organizations to enable or disable all AI-powered Risk features, including Exposure Management Insights, in a single, governed action.

This feature ensures that AI capabilities are only activated with explicit administrator consent and full acknowledgment of the associated legal terms.

Enhancement

151197

ExPayment: Fix Intermittent FTP Connection Failures during Fingerprint Validation

The FTP transport service has been updated to properly validate server connection state before fingerprint verification, eliminating intermittent failures during payment extract jobs.

The fix includes connection state checks and handshake timing improvements to ensure stable FTP connections under varying network conditions, preventing ExPayment job failures during the transport phase.

Enhancement

150244

ExPayment: Robust Null Handling and Structured Logging

This update enhances system stability and observability by adding full null handling safeguards within TransformDataByGFS to prevent runtime exceptions, supported by new unit tests for edge cases. Logging has been upgraded to structured, New Relic compatible output with enriched metadata for clearer diagnostics while ensuring sensitive data is masked.

Additional error recovery logic improves handling of unauthorized GFS responses, and overall code quality has been refined for better readability and maintainability.

Enhancement

152684

Selected Transactions not sent to SWIFT

Fixed a critical issue where single-transaction payment files were being overwritten during the GFS / SecureSend transmission process, causing payments marked as "extracted" to fail delivery without error logging.

The system now appends unique Transaction IDs to all filenames and includes enhanced exception handling in SecureSend, ensuring 100% delivery of extracted payments with full error visibility and preventing silent transmission failures.

Fixed

151198

ExPayment >Transport Files to FTP: Job status stuck in processing

Fixed an issue where payment extract jobs would remain stuck in "Processing" state after a successful FTP retry, even when files were successfully delivered to the remote server. Jobs now properly transition to "Completed" status following successful "Transfer to FTP" operations, eliminating the need for manual database intervention when retrying failed jobs after FTP connection corrections.

Fixed

151916

ExPayment Formatting: Incorrectly identifying investment account numbers as IBANs and outputting the account value in incorrect XML tag.

Fixed incorrect IBAN detection logic that was causing SWIFT file rejections when account numbers coincidentally started with valid country codes (e.g., "SMTCJPJT" starting with "SM" for San Marino).

The system now validates IBANs using proper structural rules including length verification, check digit validation, and MOD-97 checksum calculation, ensuring only legitimate IBANs are tagged as such while correctly handling non-IBAN account numbers in the <Othr><Id> format.

Enhancement

153360

SSO Login Error Handling Improvements

Resolved a database connection issue that caused a performance degradation when SSO services were invoked.

Fixed

153119

Navigation from Users to User Groups

Resolved problem were users couldn’t navigate directly from Users to User Groups when CDN feature flag is enabled.

Fixed

153365

Dashboard Balance Widget displaying Balances for Users with No Rights to Balances

Resolved an issue that was preventing the proper application of the view balance security permission when viewing the Balance dashboard widget on the home portal in some use cases. This update will ensure that users with proper access will be prevented from viewing balance details as expected.

Enhancement

152959

Basic Authentication support for External API: v2 API

The Basic Authentication enhancement provides an additional security option for your External API integrations. This is an optional upgrade that requires no immediate action. Your existing integrations will continue operating exactly as they do today.

When you're ready to adopt enhanced security controls, the v2 authentication method will be available for your use.

Migration is straightforward. You only need to update your authentication call to use the new endpoint at [environment]-job-api.Ripple Treasury.net/api/Auth/V2/auth/external/request-token with Basic Authentication. Note that v2 uses a different base URL with the -job-api suffix. The token returned in the response 'data' field works identically to v1 tokens, so no other code changes are required.

You can migrate integrations at your own pace, testing thoroughly in non-production environments before making any production changes.

If you have questions about this enhancement or would like guidance on adoption strategies, please contact your Customer Success Manager or our Support team.

Enhancement

151958

Adding HONIA to the list of dropdowns for float rates

Added new HONIA overnight basis to HKD.

Enhancement

153515

Addition of China LPR

Added CNY LPR rate.

Enhancement

153516

Add PHP FX Vols

Added PHP FX vols.

Enhancement

153302

Commodity Forward: Lithium Hydroxide

Added Lithium Hydroxide as a new commodity.

Enhancement

153118

OPELLA require additional market tickers

Added BIF, FKP, KMF, KPW, and MDL currencies.

Fixed

110820

OCI not showing in the accounting report for trades with early close

This is to fix the standard and enhanced accounting report to show the OCI value for trades with early close.

Enhancement

151786

Add currency basis support to implied rates

The calculation of the rate on the hypothetical derivative for cross currency swap cash flow hedges has been changed. The previous method was to calculate the rate for a zero value excluding currency basis and this has been changed to the rate for a zero value including currency basis.

This was done to align the rate on the hypothetical more closely with the actual hedge. This will not affect hedge relationships that have already been processed.

Enhancement

153006

Non-Cash Event Journal Export with Settled Cash Flow Configuration

Issue:

• You can configure the system to export journal entries only for cash flows in "Settled" status, while continuing to include valuation and accrual accounting journals as usual. Under this configuration, all cash flows not marked as "Settled" in the settlement process would correctly be excluded from export.

• However, non-cash flow events, such as withholding tax events, were incorrectly excluded from the journal export under this configuration. This required manual adjustments to accounting postings to capture these events.

Resolution:

• The system now correctly exports all non-cash flow events, accrual journals, and valuation journals regardless of the settled cash flow configuration setting. Clients can continue to restrict journal generation to cash flows in "Settled" status while ensuring complete export of all non-cash, accrual, and valuation journals.

Impact:

• This fix eliminates the need for manual accounting adjustments and ensures comprehensive journal export, improving accuracy and efficiency in the accounting close process.

Fixed

153009

FX Options Credit Adjustment Accounting Event Generation

Issue:

• When generating accounting events for FX options with credit adjustments, the system required the FX option expiry date to align exactly with the accounting report end date. If an FX option expired before the month end, an error message would prevent the accounting event from being generated.

Resolution:

• The system now handles FX options that expire before the accounting report end date, allowing accounting events to be generated successfully regardless of when the option expires within the reporting period.

Impact:

• This enhancement eliminates unnecessary processing errors and enables more accurate and timely accounting event generation for FX options with credit adjustments, particularly for options that expire mid-period.

Fixed

153010

DWH Mark to Market Data Source providing incorrect value for Deal Currency Market Value

Issue:

• When running the Mark to Market (MTM) report with credit adjustment enabled, the standard treasury MTM report correctly displayed:

  • Credit adjusted MTM value in reporting currency

  • Unadjusted MTM value in reporting currency

  • Credit adjusted MTM value in deal currency

  • Unadjusted MTM value in deal currency

• However, when exporting this data to the data warehouse for custom reporting purposes, the credit adjusted MTM value in deal currency and unadjusted MTM value in deal currency were inconsistent with the values shown in the standard treasury MTM report.

Resolution:

• Data warehouse exports now align consistently with the standard treasury MTM report, ensuring all credit adjustment values, including those in deal currency, match across both reporting channels.

Impact:

• This fix ensures data integrity and consistency between the standard treasury MTM report and custom reports built from data warehouse exports, enabling accurate analysis and reporting of credit-adjusted positions.

Fixed

153043

Cash Account Face Value Calculation in Security Report

Issue:

• In the security report, face value is calculated dynamically based on the user-selected reporting date to show the outstanding face value of all securities as of the end of that reporting date. This allows users to easily trace back to historical data for reporting and analysis purposes.

• However, Cash Account instruments were incorrectly reporting the outstanding balance of the next scheduled principal movement instead of the balance as of the reporting date. This caused inconsistencies when aggregating balances of all instruments in the security report for a specific reporting date.

Resolution:

• Cash Account instruments now correctly report the outstanding balance as of the selected reporting date, consistent with how all other securities are calculated in the report.

Impact:

• This fix ensures accurate historical balance reporting and consistent aggregation of all instrument balances in the security report, improving data integrity for reporting and analysis.

Fixed

153142

Treatment of a Custom Schedule (amortizing swap) in Reprice Gap Report

The gap report in the ALM module has been fixed for treasury instruments with custom schedules and fixed rates. Previously the total balance was appearing at the final maturity date. Now the full amortizing balances are spread out over the period.

Fixed

152716

FRN Trading Margin Calculation Accuracy Fix

Corrected a calculation precision issue in the Floating Rate Note (FRN) Trading Margin computation.

Issue:

• The system's FRN trading margin calculation produced results that differed from market standard calculations, resulting in reduced precision when compared to industry benchmarks.

Resolution:

• The FRN trading margin calculation has been updated to align with market standards, providing improved accuracy and precision in margin computations. The reported yield has also been corrected to be the current overnight rateset plus the calculated trading margin.

Enhancement

152078

Securities report from native reports: add "Next Principal Amount" and "Next Principal Payment Date" to the report

The Securities Report has been enhanced to include 2 new data fields:

• Next Principal Amount: Upcoming principal payment amount for each security

• Next Principal Payment Date: Scheduled date of the next principal payment

Fixed

151865

In the Securities report, the "Next payment amount" field displays an incorrect interest payment.

The Securities Report was displaying understated values in the Next Payment Amount column for securities where the next payment contains compounded interests from multiple interest periods. The report captured only the first interest period rather than aggregating all compounded periods.

The Securities Report now aggregates all compounded interest periods when calculating the Next Payment Amount. The calculation sums all interest periods associated with a payment event, ensuring the total reflects the complete payment due.

Enhancement

150064

Unified User group permissions not working in Reporting

Enhanced user access permissions so [Reporting Module].[Report Writer].EXEC permission now controls access to the custom reporting functionality. Now when the permission is granted, users will be able to see the below menu items, and those users without this permission will no longer see the below menu items.

• Reporting > Dashboards

• Reporting > Custom

• Reporting > Instant

• Reporting > Repository

This was done to align the permission with our documentation and to correct an issue where users without reporting permissions where still able to access custom reporting.

Enhancement

150064

Unified User group permissions not working in Reporting

Enhanced user access permissions so [Reporting Module].[Report Writer].EXEC permission now controls access to the custom reporting functionality. Now when the permission is granted, users will be able to see the below menu items, and those users without this permission will no longer see the below menu items.

• Reporting > Dashboards

• Reporting > Custom

• Reporting > Instant

• Reporting > Repository

This was done to align the permission with our documentation and to correct an issue where users without reporting permissions where still able to access custom reporting.

Fixed

151762

360T Connector HTTP client timed-out error

Created a minimum 20-minute timeout to address the timeout error.

Fixed

145286

Hedged Item Page: Expanded Exposure Descriptions Character Limit to 500 characters

Increased the character limit of the Exposure Description on the Hedge Item page.

Enhancement

151977

Auto-populate Price for MMF Deal Instrument Opening Balance Investment

When you create an MMF deal instrument with a non-zero principal amount as the opening balance, the system now automatically sets its price to 1. Previously, investments added via opening balance without explicit price or unit information would remain in a "pending" status, requiring manual intervention before you could proceed.

How it works:

• Add a new MMF deal instrument with a non-zero opening balance

• The system automatically creates an investment entry in the Movement tab

• The price field is pre-populated with a value of 1 (instead of showing "pending")

• You can manually adjust the price after the movement is created if needed

Fixed

150807

Incorrect Principal Rollover Event Created During Margin-Only Amendments in Loan / Deposit Instrument

When amending a custom schedule to change only the margin in Loan / Deposit instrument, the system incorrectly generated a principal rollover event in the Events tab, even when no rollover existed prior to the amendment.

The system now correctly handles margin-only amendments to custom schedules without creating erroneous rollover events. Event types are preserved accurately based on the actual changes made.

Fixed

150156

CCIRS Exposure Calculation Improvement for Limit Dashboard and Credit Exposure Report

Principal-based exposure calculations for Cross-Currency Interest Rate Swap (CCIRS) deals produced inaccurate results when the receiving leg currency differed from the valuation currency. This affected exposure figures displayed in both the Limit Dashboard and Credit Exposure reports.

The face value and initial principal calculation for CCIRS instruments now:

• Identifies the valuation currency

• Retrieves the matching leg principal

• Converts it to the reporting currency using the current spot rate, only when it is different from valuation currency

This enhancement provides stable and consistent exposure reporting for CCIRS deals, enabling more reliable limit monitoring and credit risk management across all currency combinations.