IBM Support

Release notes for IBM Financial Transaction Manager for Digital Payments 3.2.13 Multiplatforms

Release Notes


Abstract

Release notes for IBM Financial Transaction Manager for Digital Payments 3.2.13 Multiplatforms

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 Digital Payments for Multiplatforms see the download document for IBM Financial Transaction Manager for Digital Payments for Multiplatforms 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.


Web Services
The following documentation describes the new web services, which are implemented by using IBM WebSphere Application Server Liberty:

  • IBM_FTM_Web_Services_v3.2.13.0.pdf

These documents are provided in the entitled documentation fix pack.
 

General instructions

Installation

  1. Start IBM Installation Manager.
  2. Add the location of the repository that contains the installation package:
    1. Select File > Preferences.
    2. Click Add Repository.
    3. Browse to the directory that contains the repository .zip file and select the file. Click Open and then OK.
    4. Click Test Connections and then OK.
    5. Click OK.
  3. Install the FTM product installation files to your installation directory:
    1. On the main pane, click Update.
    2. Select IBM Financial Transaction Manager for Digital Payments, IBM Financial Transaction Manager for Corporate Payment Services, or IBM Financial Transaction Manager for High Value Payments, and then click Next.
    3. Select the fix pack or interim fix and then click Next.
    4. Follow the rest of the prompts.
    5. Confirm that the "Update packages" page shows success.


Deployment

  1. Do the database migration. Refer to the Database migration section in this document.
    1. Note: The runtime components can’t be running during the database migration.
    2. Note: Files can continue to be delivered to the Gateway inbound source folder.
  2. J2SE components: The installation overlays the J2SE applications, so no special migration instructions are needed. Restarting those applications updates them with the fixes.
  3. WebSphere Application Server components: You can use the Automated Deployment Utility (ADU), manually upgrade (refer to the update instructions in each WebSphere Application Server component doc folder), or, in a WebSphere Application Server Network Deployment configuration, use the Deployment Manager.
    Note: Refer to "WebSphere Application Server 9.0.x update issue" in "Common Across Releases" > "Known Issues".
    1. All WebSphere servers must be restarted after all the components were updated.
    2. For an interim fix, refer to the fix list for the modules to deploy. Note: Interim fixes are meant to be deployed on an existing WebSphere Application Server profile deployment. If you are using a new WebSphere Application Server profile and already installed the interim fix onto the prior installation, you must do two deployment passes. The first pass is to do the initial, full product deployment. The second pass is to do those components that are affected by the interim fix.
  4. Update your Transaction Server Scheduler.xml file. Refer to the Transaction Server Scheduler XML section in this document. Note: Updating the scheduler file might not be required for your installation.
  5. Refer to the release-specific section for any changes that might affect your installation.
  6. Start your runtime components.
  7. If you are using the Data Setup Utility (DSU) worksheets capability for managing your data, update your worksheets. For more information, see the Data Setup Utility section in this document.
  8. Beginning in FTM 3.2.13.0, the user interface is no longer installed in WebSphere Application Server but instead is deployed to the Red Hat OpenShift Container Platform (OCP).  You can generate the Custom Resource Definition required for the OCP deploy using the PFS Tools utility.  You can make customizations to the CRD and then use it to complete the user interface deployment.  For full instructions, see the FTM 3.2.13 online product documentation.  For interim fix migration, see the OCP Migration document in the entitled documentation fix pack.
Caution: The FTM operator is set to auto-deploy by default. IBM recommends changing this to manual deploy (installPlanApproval: Manual). See the following page in the IBM Documentation for details on how to make this change.
Installing and configuring a server for IBM WebSphere Application Server Liberty

Locate the compressed file for WebSphere Application Server Liberty that is stored in the following path:

 <installation directory>/ftm/vxxx/run/liberty
 Where xxx = represents current FTM version that is running. For example, 3213.

Decompress the file in your preferred path: <liberty-install-directory>. For example, /opt/wlp/.

Follow the following steps to create and configure the server:
  1. Create your server with <liberty-install-directory>/bin/server create PFSServer.
  2. Modify the server.xml.template file located in FTM installation path <installation directory>/shared/vxxx/pfs/WebServices/Liberty/PFS with config values for your install (refer to the following list of things that need to be modified).
  3. Rename that file server.xml
  4. Copy server.xml and jvm.options into <liberty-install-directory>/usr/servers/PFSServer.
  5. Start your server with <liberty-install-directory>/bin/server start PFSServer --clean (--clean is optional).

Things that need to be modified in the server.xml.template depending on environment details:
  • Db2 installation location, database name, and port.
  • IBM MQ installation location, queue manager name, user, password, and port.
  • The db2admin user and password.
  • Set currentPackagePath, currentFunctionPath, and currentSchema to your schema name.
  • Set the password for the FTM administrator ID, which is usually fxhadmin.
  • You must ensure that you create a server or update an existing server to run the new version of the IBM WebSphere Liberty RESTful web services.  For more information, see https://www.ibm.com/docs/SSRH46_3.2.13/gpyiybrinstlibty.html
Extra parameters might need to be adjusted depending on your usage.

Back to contents
Common Across Releases

None

Back to contents
Supported Early Warning Services (EWS) notifications and SOAP requests

Version 3.2.13

FTM was upgraded to the 4.8 EWS WSDL for Zelle processing. The upgrade to the new version of EWS also allows for possible future enhancements without the required WSDL version upgrade to the product.  The minimum EWS version required for FTM 3.2.13 is EWS 4.8.  

The following is a list of supported EWS notifications and supported EWS SOAP requests.
Supported EWS notification Version
OnNewPaymentStatusNotification 4.8
OnCustomerChangeNotification 4.2
OnPaymentProfileStatusChangeNotification
OnNewPaymentNotification 4.0
OnTokenStatusChangeNotification 4.3
OnNewPaymentRequestNotification 4.2
OnOrganizationsChangeNotification 4.0
OnPaymentRequestChangeNotification 2.4
OnContactMethodWarningNotification 4.3
OnPaymentStatusChangeNotification 4.3
Supported EWS requests Version
AddPaymentRequest 4.1
ChangePaymentRequestRequest 4.0
ChangePaymentStatusRequest 4.6
DeletePaymentProfileRequest
GetCustomerEventDetailsRequest 4.0
GetOrganizationsRequest 4.0
GetPaymentRequest 4.3
GetPaymentRequestDetailsRequest 4.2
GetPendingActivityForTokenRequest 3.2
GetTokenHistoryRequest 4.3
GetTokenStatusRequest 4.2
RegisterTokenRequest 4.5
RemoveTokenRestrictionRequest 4.2
RequestPaymentsRequest 4.2
RestrictTokenRequest 4.2
UnregisterTokenRequest 4.2
UpdateBusinessPaymentProfileRequest 4.0
UpdatePersonalPaymentProfileRequest 4.0
ValidateRecipientRequest 4.2
Supported EWS RESTful Requests
zpss/v1/active-profiles
zpss/v1/available-profiles
 
Back to contents
3.2.13.0 interim fix 5
Feature Changes
None
Known Issues
Known Issue 1
Issue: If you are experiencing an issue where the raw data link is not working for Nacha files on the Inbound Transmission's transmission hierarchy page, this is a symptom that Control Center container does not have the proper access to the Gateway Server file system.
Workaround: Please work with your system administrator to enable the Gateway server file system to mount via a NFS share with the proper permissions to be read by Control Center container.
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
None
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
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
 

Compatibility Matrix


Because the development of releases and interim fixes for maintenance are done in parallel, a later release might not contain every interim fix that was created for an earlier release. The following table shows which releases and interim fix levels can be successfully upgraded to version 3.2.13.0.

In the following table, the "If you're on version" column shows you the releases that can be upgraded successfully. The latest release or interim fix level that can be upgraded for each release is shown in the "To successfully upgrade to 3.2.13.0, your version must be no higher than version" column. If the release that you are upgrading from is at an interim fix level higher than the release or fix level shown in the right column, you can't upgrade the release without losing some changes. The upgrade needs to occur at the next release.

For more information about the individual changes in a release or interim fix, see the fix list for this version.
If you’re on version To successfully upgrade to 3.2.13.0, your version must be no higher than version
3.0.2.0 3.0.2.0 interim fix 2
3.0.2.1 3.0.2.1 interim fix 23
3.0.4.0 3.0.4.0 interim fix 3
3.0.4.1 3.0.4.1 interim fix 1
3.2.0.0 3.2.0.0 interim fix 1
3.2.0.1 3.2.0.1 interim fix 2
3.2.1.0 3.2.1.0 interim fix 3
3.2.2.0 3.2.2.0 interim fix 5
3.2.2.1 3.2.2.1 interim fix 3
3.2.3.0 3.2.3.0 interim fix 5
3.2.4.0 3.2.4.0 interim fix 17
3.2.5.0 3.2.5.0 interim fix 6
3.2.6.0 3.2.6.0
3.2.6.1 3.2.6.1 interim fix 6
3.2.7.0 3.2.7.0 interim fix 2
3.2.8.0 3.2.8.0
3.2.8.1 3.2.8.1 interim fix 4
3.2.9.0 3.2.9.0 interim fix 10
3.2.9.1 3.2.9.1 interim fix 1
3.2.10.0 3.2.10.0 interim fix 6
3.2.10.1 3.2.10.1 interim fix 2
3.2.11.0 3.2.11.0 interim fix 2
3.2.11.1 3.2.11.1 interim fix 5
3.2.12.0 3.2.12.0

Feature changes

New User Interface changes starting in FTM 3.2.13

Overview

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

 
Leveraging the Risk Insights scores from Early Warning Services as part of validation of received Zelle transactions from the network.
 

Overview

FTM has been updated to use the OnNewPaymentStatusNotification4.8. And, when RIZ scores are provided by EWS, FTM will pull those values from the notification and provide them to the customer's Fraud User Exit for proper evaluations.

Back to contents

Zelle Settled

Overview

During Zelle reconciliation of received payments, an additional EWS ChangePaymentStatus call is made to update the payment status at EWS (and passed along to the originator of the payment) to "Settled".  That same "Settled" status will also be reflected in FTM.  For standard received payments, the "Settled" update will occur after successful reconciliation and funds transfer.  For expedited payments, the "Settled" update occurs after successful reconciliation (funds transferred occurs when the payment is initially received).

Back to contents

Zelle DNTD v3 Support

Overview

Support for Debit Network Transaction Detail (DNTD) v3 Record Specification which provide Participants with additional detail about Supported Debit Card Payments.  Added support for 8 new v3 fields which can be verified in inbound transmission hierarchy (Transaction details under Debit Card Information tab).

Back to contents

Zelle Accept without Post

Overview
If for any reason (Fraud, KYC, Limits, Accounting, Zelle API Pause, etc.), the system accepts the payment instruction, but doesn't post the beneficiaries account immediately, FTM will respond with the "Accept without Post" notification.  If or when the issue is resolved and the money is posted to the beneficiary's account, FTM then provides the subsequent notification that it has completed.

FTM Partner ID vs Participant ID

Overview

This change applies to bank customers who have an internal FTM Partner ID that is different from the EWS Participant ID.  Starting with the 3.2.13 release, the internal FTM Partner ID is no longer used in EWS API calls.  Instead, the EWS Participant ID is now used for EWS API calls.  These customers will continue to see all of their payments that have been made with either FTM Partner ID or EWS Participant ID.

Deprecated APIs removed

Overview

The following APIs deprecated in previous FTM releases were removed:

Create InitiateCreditTransfer
POST
http://host:58080/ws/svc/initiateCreditTransfer/
Deprecated as of 3.2.9. Use /transactions/initiatecredittransfer_v2

Create InitiateRequestForPayment
POST
http://host:58080/ws/svc/initiaterequestforpayment/
Deprecated as of 3.2.8. Use /transactions/initiaterequestforpayment_v2

Create RequestForInformation
POST
http://host:58080/ws/svc/reqinfotrans/
Deprecated as of 3.2.9. Use /transactions/reqinfotrans_v2

Create RequestReturnOfFunds
POST
http://host:58080/ws/svc/reqretfunds/
Deprecated as of 3.2.8. Use /transactions/reqretfunds_v2

Create ResponseToRequestForPayment
POST
http://host:58080/ws/svc/responsetorfp/
Deprecated as of 3.2.8. Use /transactions/responsetorfp_v2

Create ResponseToRequestReturnOfFunds
POST
http://host:58080/ws/svc/responsetorrof/
Deprecated as of 3.2.8. Use /transactions/responsetorrof_v2

Customizations

Updates to 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)

In 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 enable or disable an authorization filter using Authorization Filter details dialog, which is opened by clicking on 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.

Create Zelle Participant Version, Activate (11934)

New version is only available for the active version on Zelle participants. This means when activating a participant, you might not get an option to create a new version for the just activated version. The workaround is to go into the list of versions and select the active version.

Issues with Request For Payment web service

Request for Payment requests that use the web services currently have the following limitations:
The code in the Referred Document Information is not mapped, and is not sent to TCH. 
For requests that use the BldgNb, in <Dbtr>, <UltmtDbtr>, <Cdtr>, <UltmtCdtr>, the data is not sent to TCH. This issue limits the ability to use the BldgNb data.

WebSphere Application Server 9.0.x update issue

WebSphere Application Server 9.0.x has a known problem updating components for an interim fix.

Automated Deployment Utility workaround:

The interim fix components to update need to be first uninstalled.  The tokens file, for example pfs_deploy.xml, contains those interim fix components to update.  These components appear in the <install> </install> section.  You also need to add these same components in the <uninstall> </uninstall> section.
 
Manual update workaround:

Before the console WAR modules are updated, stop the FrameworkUI_EAR application, and then proceed as normal.  The engine modules can be updated as normal.

OFAC Simulator not working

If the sample control file is updated, the OFAC Simulator fails due to a missing required attribute, Business Concept.

- The OFAC Simulator control file is located in installation directory\shared\v3213\pfs\Vetting\samples
- The sample that is installed with FTM, which lists a single error code, works as expected
- If the sample control file is updated to contain multiple error codes, the OFAC Simulator generates an event failure message due to the missing required attribute, Business Concept

Potential issue with Cancel Request For Payment web service

When the Log Transaction setting on the "Request To CSM" Channel configuration is updated to Yes (Y) in FTM for Immediate Payments, the Cancel Request For Payment Web Service could fail when it tries to correlate transactions. It is recommended that the Log Transaction setting for the "Request To CSM" Channel configuration remain set to No (N).

SchedulePaymentModel issue

If the SchedulePaymentModel web service is being used to create a TCH RTP transaction, the Instruction for destination field in the web service call must not be used. TCH RTP placed schema restrictions on the Instructions for Creditor Agent that are not supported by the web service currently.

Held files might be incorrectly flagged as duplicate.

Transmissions that are held or pending (based on the error code or rule set configuration) might be incorrectly flagged as duplicates. If the transmission is accepted (from held or pending), the "duplicate" held or pending transmission is resolved.

Outbound physical transmissions page might provide more restrictive results to users without entitled access

When a restrictive entitlement is configured, users must be configured to have that entitlement before they can view the entitled data. The outbound physical transmissions page incorrectly restricts the data based on the inbound data fields. So, nonentitled users have a more restrictive view of the outbound physical transmission page.

 

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

Document Information

Modified date:
03 September 2025

UID

ibm17171499

Page Feedback