IBM Support

Release notes for IBM Financial Transaction Manager for High Value Payments 3.2.13 Multiplatforms

Release Notes


Abstract

Release notes for IBM Financial Transaction Manager for ISO 20022 High Value Payments 3.2.13 Multiplatforms

Financial Transaction Manager for ISO 20022 High Value Payments V3.2.13 offers the ability to process ISO 20022 high-value payment types. This addition to the modern, robust IBM Financial Transaction Manager suite brings together capabilities that were not available within the existing suite.

Financial institutions can now process the following payments through a single ISO 20022-compliant platform by using a common Internal Standard Format (ISF).
- T2 and EURO1/STEP1 ISO 20022 payment messages that follow the High Value Payments Plus (HVPS+) specification.
- NBO, RIX, DKK and Fedwire ISO 20022 payment messages that follow the High Value Payments Plus (HVPS+) specification.
- Swift cross border payments that follow the Cross-border Payments and Reporting Plus (CBPR+) specification.

Content

 

Before installation

System requirements

Check the IBM Financial Transaction Manager system requirements to ensure that your installation platform is supported for the product edition that you plan to install. For more information about the system requirements for all of the different versions of the product, see the IBM Financial Transaction Manager system requirements website.
 

Downloading the product

For information about how to download IBM Financial Transaction Manager for High Value Payments for Multiplatforms see the download document for IBM Financial Transaction Manager for ISO 20022 High Value Payments 3.2.13.
 

Product documentation

Data Setup Utility
The following documentation describes the data setup utility (DSU) and the import and export workbooks:

  • DSUmigration_v3.2.13.pdf
  • DSUMigrationBR_v3.2.13.pdf

These documents are provided in the entitled documentation fix pack.

Database migration
For database migration instructions, refer to the migration instructions in {Install location}\shared\vnnn\pfs\Database\db2\{os}\doc


Transaction Server Scheduler XML
The following documentation describes the changes to the scheduler XML for the Transaction Server component:

  • TransactionServerSchedulerChanges_v3.2.13.pdf

These documents are provided in the entitled documentation fix pack.
 

Back to contents
3.2.13.0 interim fix 5
Feature Changes
None
Known Issues
None
Migration

See the Red Hat OpenShift Container Platform (OCP) Migration document in the entitled documentation fix pack.

Back to contents
3.2.13.0 interim fix 4
Feature Changes
FTM operator was split into two operators
The FTM operator was split into two operators. The API operator installs the FTM custom resource definition (CRD) and can be installed once per cluster. The controller operator installs the FTM controller and must be installed in each namespace where an FTM instance is to be deployed.
Known Issues
None
Migration

See the Red Hat OpenShift Container Platform (OCP) Migration document in the entitled documentation fix pack.

Back to contents
3.2.13.0 interim fix 3
Feature Changes
None
Known Issues
None
Migration

See the Red Hat OpenShift Container Platform (OCP) Migration document in the entitled documentation fix pack.

Back to contents
3.2.13.0 interim fix 2
Feature Changes
Mapper support for MT and MX system messages
Added support for the following new messages: MT010, MT011, MT019, xSys.010
Updated support for the following messages: xSys.011, xSys.012
Known Issues
Known Issue 1
Issue: The number of "Expected events" might not match the actual count of events that are displayed on the linked page.
Workaround: On the linked "Expected events" page, use a Status equal to Overdue constraint to view the accurate number of events.
Known Issue 2
Issue: The number of "Physical transmissions in error" might not match the actual count of errors that are displayed on the linked page.
Workaround: On the linked "Physical transmissions" page, use the table filter and set the Status is Error constraint to view the accurate number of errors.
Migration

See the Red Hat OpenShift Container Platform (OCP) Migration document in the entitled documentation fix pack.

Back to contents
3.2.13.0 interim fix 1
Known Issues
None
Feature Changes
High Value Payments CBPR+ 2024 Mandates Support
Outbound MT mappers added for MT190 - Advice of Charges and MT191 - Request for Payment of Charges.
Migration

See the Red Hat OpenShift Container Platform (OCP) Migration document in the entitled documentation fix pack.

Back to contents
3.2.13.0 Release
 

New features and updates

New user interface changes starting in FTM 3.2.13

FTM 3.2.13 introduces a new user interface (UI) with an updated user experience look and feel that improves the usability of the application.  The new user interface consists of a set of containers that are deployed with an operator to Red Hat OpenShift Container Platform (OCP).  While the user interface is no longer deployed on WebSphere Application Server, the FTM backend engines are still deployed there.  For information on how to deploy the new user interface on OCP, refer to the FTM 3.2.13 online documentation.

High Value Payments CBPR+ 2024 Mandates Support

camt.105.001.02
The camt.105.001.02 (camt.105) mapper is used to inform the account owner about single transaction charges, interest, or adjustments that have been applied to their account, providing details that were previously unknown to them.The camt.105 is of Inbound mapper.
− camt.105 Inbound Mapper: Map ChargesPaymentNotification messages to ISF message. The default mapper name is camt105ToISFMapper.
The details of the mapping specification for the inbound mapper are included in a separate document. Refer to Detailed camt.105 mapping  specification for more information about obtaining the documentation for the mapping specification

camt.106.001.02
The camt.106.001.02 (camt.106) mapper is used to request payment for a single transaction charge, interest, or other previously unknown expenses to the receiver. The camt.106 is of Inbound mapper.
− camt.106 Inbound Mapper: Map ChargesPaymentRequestV02 messages to ISF message. The default mapper name is camt106ToISFMapper.
The details of the mapping specification for the inbound mapper are included in a separate document. Refer to Detailed camt.106 mapping specification for more information about obtaining the documentation for the mapping specification.

Added new Type to ISFTypes_V3.xsd <ISFCharges> which represents ISO 20022 CAMT.106.001.02 <Charges> element. This type represents information about charges to be paid by the charge bearer(s) related to the processing of a transaction.
Added new Type to ISBCTypes_V3.xsd <DebtorAccountAgent>. This type represents the financial institution that is servicing an account for the debtor. For example, the type can be used for the debtor agent of certain charges record.

Support for Nordic and Fedwire message standards

In addition to the previous new messages, FTM 3.2.13 adds support for the Nordic (NBO, DKK, RIX) payment schemes and the Fedwire payment scheme.

Customizations

Updates to the custom resource definition (11912)

If you used the PFS Tools to generate the initial draft of your custom resource definition (CRD), the solution value must be updated from 'ui' to match the solution you are installing:

  • If you are installing Digital Payments, the solution value must be dp-mp
  • If you are installing High Value Payments, the solution value must be hvp-mp
  • If you are installing Corporate Payment Services, the solution value must be cps-mp

Custom Queue Names (11587)

If FTM was set up with custom queue names, the following configuration must be done to update the FTM pods with the correct queue names.

Note:  The following configmaps can be pre-created before deploying FTM. Pre-created configmaps must have the following annotation so they are not overwritten by the FTM operator.

formation/update: disabled

Control Center pod

Edit the config-dropins.xml key of the <ftm_instance_name>-control-center-v3-dropins configmap.  Add the following XML snippet. Replace <custom_queue_name> with the name of the FXH.TRANSSERVER.INPUT.QUEUE queue. Then, restart the Control Center pod.

<jmsQueue id="jms/txs/TxsuiQ" jndiName="jms/txs/TxsuiQ">

    <properties.wmqJms baseQueueManagerName="${QMGR_NAME}" baseQueueName="<custom_queue_name>" />

</jmsQueue>

Core UI API pod

Edit the override-application.properties key of the <ftm_instance_name>-core-ui-api-properties configmap.  Edit the following line and change the value to the new name of the queue.  Then, restart the core-ui-api pod.

jms.ftm.jmsConnectionMap.tx.queues.TxsuiQ.jmsSendQueue=FXH.TRANSSERVER.INPUT.QUEUE

Secure Vault Deployment (12045)

When you are using a secure vault deployment, if any of the following values are set in an init container, both corresponding keys need to be set and with the same value:

KSTORE_PASSWORD and KEY_STORE_PASSWORD
TSTORE_PASSWORD and TRUST_STORE_PASSWORD
OIDC_CLIENTSECRET and OIDC_CLIENT_SECRET

Gateway Server Configuration (11428)

If you are configuring the Gateway Server to access WebSphere Application Server applications, WebSphere Application Server must be upgraded to 9.0.5.20 and enable SSL to communicate. Documentation on what processes the Gateway Server uses to communicate with the WebSphere Application Server applications and enabling SSL can be found in the FTM 3.2.13 online product documentation.

Known issues

This section outlines the known issues and their workarounds (if any).

Operator version number incorrect (12181)

Problem Description: The FTM operator description should not specify a specific version number since it is a single operator supporting multiple releases.  Operator version 4.0.7 was incorrectly specified in the FTM operator description, which is misleading.
Mitigation: Users should install the FTM operator from the stable-4.5 channel, and ignore the "4.0.7" in the operator description. The description of the operator in that channel will be updated to not specify the version number.

Issue with Sample User Create exit (12170)

A null pointer exception might occur when the Sample User Create exit is used.

The issue occurs because the code is trying to get a method through reflection from the wrong object class.
This occurs in the user create exit only with the JWT token and is related to around line 104

				Method getClaimAsStringMethod = oauthAuthenticationClass.getMethod("getClaimAsString",
							String.class);

Instead of getting method from the object class oauthAuthenticationClass it should be from the object class jwtClass
The line should be changed to

				Method getClaimAsStringMethod = jwtClass.getMethod("getClaimAsString",
							String.class);

Instructions for locating the sample user create exit and building it can be located in FTM Documentation in the section for Role-based authorization.

Make sure to give the recompiled user exit a new name otherwise the sample provided with the deployment is used.

Silent Install (11976)

Before you do a silent install, edit the response file silent/ftmXX_install.rsp and change v3212 to v3213.

Global Limit Monitor (11938)

When you are creating a Global Limit monitor and Monitor level is set to "Transactions" and Limit span to "Velocity", the user is not able to enter negative values for the credit and debit count fields in the Monitor Details section.

Since you cannot enter negative values for the credit or debit count, you cannot use a value of -1 to disable the monitor. The workaround for this limitation is to enter a high number that will never be reached for the count.

Create Participant, Roles (11894)

On the Participant Directory->Participants page, when a user tries to create a participant without selecting any roles, an error message "problemDetail.org.springframework.web.method.annotation.HandlerMethodValidationException" is displayed in the dialog window, although the participant creation was successful. The workaround is to add roles from participant details page. This page can be reached by closing the Create Participant dialog, refreshing the participants table, and clicking the newly created participant from the table.

Create Participant, Risk Management (11754)

On the participant's authorization filter page, which is under Participant Directory->Participants Details->Risk Management->Account Rules, whenever a user selects any authorization filter by using the checkbox in the table and tries to enable or disable a rule using the "Enable Rule" or "Disable Rule" buttons that are shown in the table's toolbar, a success notification is displayed despite that action being unsuccessful. The workaround is to enable or disable an authorization filter by using the Authorization Filter details dialog, which is opened by clicking a row in the "Authorization Filter" table.

Participant Activation (12000)​

Participant activation might fail for participant with message "There are validation errors in participant that need to be corrected" after creating scheduled payment. The workaround is to go to Originator -> Recipient, click the recipient item in the table, go to the Preferences tab, and make sure the required fields Payment scheme and message type are set.

CORBA marshalling error indicating an exception class not found (11766)​

A CORBA marshalling error indicating an exception class is not found may be logged by the Control Center when a failure occurs in a remote call to an engine component (e.g. Services Framework, Gateway Engine, Distribution Engine, etc.). The initial failure (root cause) is in the engine. The marshalling error logged by Control Center is a by-product. Root cause analysis needs to focus on the engine component, so it's important to provide log information from the engine servicing the request.
A future release will correct error handling and logging in the Control Center for failures in remote calls to engine components.

ISF Agent Role ambiguity (8458)

ISO 20022 Messages such as - PACS.008 or PACS.009, might contain the mandatory <InstgAgt> structure, and optionally one or more of <PrvsInstgAgt1>, <PrvsInstgAgt2>, <PrvsInstgAgt3>.

Current Maps for these elements results in ambiguity in mapped ISF document, where both <InstgAgt> and any of <PrvsInstgAgt{X}>, where {X} is the elements suffix number in the original message , are each mapped to structures with root element
<AgentRole xsi:type="isf:InstructingAgentRole">

This causes problem(s) for Business Rules validation because this mapping cannot be reversed in a unique way.

Solution - New element <Position> added to ISF AgentRole[xsi:type=isf:InstructingAgentRole] to reflect the original ISO 20022 Message <PrvsInstgAgt{X}>.
<Position> element is used to uniquely identify and properly map PreviousInstructing{X} Agent under instructingAgentRole in ISF .
<Position> element shows number of PreviousInstructing agent mapped in ISF .
Which provides Business Rules with clear Xpath to validate message data and also helps to map <PrvsInstgAgt{X}> in outbound scenario properly.

Fedwire pacs.009 validation not correct (10991)

For Fedwire pacs.009, error code FW224 does not display when ‘IntermediaryAgent1’, ‘InstructedAgent’, and ‘CeditorAgent’ are the same.  The IntermediaryAgent1 should only be allowed if different from the InstructedAgent and the CreditorAgent.  In the current release, it is possible to have the same value for all three fields without generating the validation error code of FW224.

Fedwire camt.056, camt.029 have discrepancy in some fields displayed in Control Center UI (10660)

Messages camt56/camt29 in Control Center user interface for Fedwire have discrepancy in some fields with respect to other schemes. Outgoing camt.056 messages are not assigned with an endpoint and display with incorrect 'Outbound Message Standard' and 'Outbound Message Type' values in Control Center.

DKK/Fedwire camt.029 inbound transactions may have misleading values (5989)​

"Non Payment" transactions (camt messages, etc.) are assigned with System Currency as the default value for the Inbound Currency column in the Inbound Transactions screen.

Fedwire pacs.004 version 10 schema validation error (5004)​

The default RANK_FOR_NOTIFICATION for incoming messages from Fedwire is CHANNEL3. A notification (ISF Message) is sent to the channel for all message types.

Migration

None.

[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSENX3","label":"IBM Financial Transaction Manager for High Value Payments"},"ARM Category":[{"code":"a8m50000000ClaTAAS","label":"Product Documentation"}],"ARM Case Number":"","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"}],"Version":"3.2.13"}]

Document Information

Modified date:
13 August 2025

UID

ibm17171501

Page Feedback