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

Product documentation

• Release information (this document)
• System requirements website
• Fix list (key defects fixes in this release)
• Financial Transaction Manager online product documentation
• Resources (support links for this and other releases of this offering)
• Entitled documentation fix pack (download from Fix Central) - updated for 3.2.11 Fix pack 1
• Mapping Specs - 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 Check Services, 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.

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

• 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.
• WAR file deployment location: the path to the Web Services WAR file <installation directory>/shared/vxxx/pfs/WebServices/Liberty/PFS/WebServices_PFS.war.

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.11, Fix Pack 1 or later

The minimum EWS version required for FTM 3.2.11.1 is EWS 4.5.

 

The following is a list of supported EWS notifications and supported EWS SOAP requests.

 

Supported EWS notification	Version
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.0
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	3.10
RequestPaymentsRequest	4.2
RestrictTokenRequest	3.10
UnregisterTokenRequest	3.10
UpdateBusinessPaymentProfileRequest	4.0
UpdatePersonalPaymentProfileRequest	4.0
ValidateRecipientRequest	4.2

Supported EWS RESTful Requests
zpss/v1/active-profiles
zpss/v1/available-profiles

 

 

Version 3.2.11

The minimum EWS version required for FTM 3.2.11 is EWS 4.4. 

The following is a list of supported EWS notifications and supported EWS SOAP requests.

 

Supported EWS notification	Version
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.0
DeletePaymentProfileRequest
GetCustomerEventDetailsRequest	4.0
GetOrganizationsRequest	4.0
GetPaymentRequest	4.3
GetPaymentRequestDetailsRequest	4.2
GetPendingActivityForTokenRequest	3.2
GetTokenHistoryRequest	4.3
GetTokenStatusRequest	4.2
RegisterTokenRequest	4.3
RemoveTokenRestrictionRequest	3.10
RequestPaymentsRequest	4.2
RestrictTokenRequest	3.10
UnregisterTokenRequest	3.10
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.11 Fix pack 2

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

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.11.2, 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.11.2, 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 7
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 9

 

 

Back to contents

 

---

 

Known issues

• When you use FTM Cognos report, the issues you might encounter are show in the following list

      - A login error: The login failed for the following reason...
      - The database test connection shows that the query is dynamic 
  
  Action
  These messages indicate that the version of FTM Cognos report is not compatible with Cognos Dynamic Query Mode (DQM). Contact IBM Support for options. 

 

• All payment schemes 
  Scheduled tasks in the Transaction scheduler.xml that are scheduled based on days or bdays may not fire at proper time after time change. 
  
  Action 
  After switching from standard time to daylight savings time and vice versa, verify that tasks are running at the proper time. This can be determined via running the Transaction server diagnostic command "list schedule" from the Components UI. If it is off, alter the starting time or date to get it back in sync. 

 

Back to contents

---

Feature changes

 

Zelle Mandates for 2024/2025 (12801) 

As an FI that processes Zelle Transactions, I need to implement any/all mandates and some optional capabilities supported by the v4.9 specifications: 

 

    - The new "time limit" on Standard Payment Failure messages (i.e. not more than 30 days) as documented in the September Nofitication of Change document

    - The optional use of SSN and DOB when registering a token

 

---

 

Zelle: Support for birthdate (required) and tax payer id (optional) (14171) 

To provide additional protection that prevents bad actors from using the Zelle® Payments Service, the Network Operator is requiring Participants provide additional information about their consumer when registering the consumer for the service or registering a new Token for their Customer. In addition to the registration information described in the Zelle® Shared Directory 4.9 Technical Specifications, Participants must now provide the following:
 

    - Consumer’s date of birth. This is required for all consumer registrations.

    - Taxpayer Identification Number. This is conditionally required by which the Participant provides the taxpayer ID when there is a taxpayer ID on file for the consumer

The Network Operator is updating the Register Token API and including these new fields:

Field Name	Optionality
date-of-birth	Required
taxpayer-id-number	Conditional

The Network Operator will use the additional consumer data provided during the registration to determine whether to complete or block the registration. Participants may override a registration block by populating “true” in the “add-to-exclusion” field of Register Token API.

 

---

 

Zelle: [MANDATE for Apr 30, 2026] Ability to Block Payments & Payment Requests (19472) 

As an FI processing Zelle payments, I must continue to keep up with network mandates. As of the April 2025 Notification of Change, the Zelle network is mandating that I am able to block both payments and payment requests in a handful of use cases, as well as properly handle "blocked" responses from the network. 

The FTM solution needs to provide APIs to facilitate these use cases from the Mobile UI (those screens and workflows are documented in the Zelle UI documentation), as well as the ability to do the same operations from the Payment Authorization service UIs within the FTM UI. We need to be able to see "blocked" status from there, as well as in the participant directory (as extra credit), from the Token UIs, etc.

 

---

 

Zelle documentation updates 
The Zelle documentation that is included in the entitled documentation fix pack was updated. The link to use to get the entitled documentation fix pack is in the Product documentation section.

 

---

 

Add support for TCH RTP V5.0 (11187) 

To update the function in TCH RTP to match the TCH RTP 5.0 specifications the following updates were carried out
 

• Update required mappers to match TCH RTP Message Specifications v5.0
• Update Web Services to match TCH RTP 5.0 Specifications
• Update the TCH RTP work flows to match 5.0 Soecifications

 

Back to contents

---

 

Back to contents

3.2.11.1 interim fix 9

Known Issues 
None

---

Feature changes

 

 

Release Notes for DOB/TPID

 

The Create CXCToken API was modified to have 3 new optional parameters:

dob (date of birth)

pid (tax payer id)

excludeEwsFraud

 

The date of birth and taxpayer id parameters are not verbosely named, and the data (if provided) is required to be Base64 encoded to obfuscate the fields. When the Create CXCToken request is received with the dob and tpid fields included, then FTM will Base64 decode this data and continue processing. Before registering the token with EWS, the token enrollment method on the FI’s Fraud user exit is always called (when installed). The FI’s Fraud user exit can add/update the date of birth and the taxpayer id data as well as the new excludeEWSFraud data field in the supplied CXCToken data object. This data would be supplied in the clear (not Base64 encoded).

NOTE: Any data updated by the FI’s Fraud UX will take precedence over any data provided on the API call.

 

FTM will use the data from the CXCToken data object when calling EWS’ Register Token API which would potentially include any/all of date of birth, taxpayer id, and excludeEwsFraud to determine what values to send to EWS on the RegisterToken API.

 

EWS has further validation requirements for the dob and tpid fields. 
For the dob field, the participant should be at least 13 years old. 
The dob format is ISO Local Date yyyy-mm-dd, example '2011-12-03'. 
For the taxpayer id, this can hold the value of SSN or ITIN.

 

These are the errors returned if the validation fails: 
"152310: Date of birth failed to match the required format" 
"152311: Date of birth younger than required" 
"152320: Cannot create token. Tax payer Id input failed to match the required pattern".

 

A new sendTokenRegistrationFailed API method was added to the UserSendNotificationInterface. This API takes the CXCToken data and the error code exception message (the reason that it failed) as parameters. This allows the user exit to determine what messaging should be sent to the participant and/or other actions that may be needed (storing Fraud data, etc).

 

---

 

Migration 
None

 

 

---

 

Back to contents

3.2.11.1 interim fix 8

Known Issues 
None

---

Feature changes 
None

---

Migration 

None

 

 

---

 

Back to contents

3.2.11.1 interim fix 7

Known Issues 
None

---

Feature changes 

New function has been added to support the updated Zelle mandate for 2025. This function covers: 

• Update to version 4.9 EWS wsdl
• Update register token to EWS version 4.9
• Support for birthdate and tax payer id
• EWS notification support for OnTokenStatusChange and OnCustomerChange to EWS version 4.7

For the Zelle mandate an update to the DB has been done and Database migration will need to be run. Please follow Migration document "dbifixinstructionsdb2_luw.txt" located in (..\shared\v3211\pfs\Database\db2\{os}\doc)

---

Migration 

None

 

 

---

 

Back to contents

3.2.11.1 interim fix 6

Known Issues 

Defect 16184 - The CXCExpirePaymentsTask allows the Payment Request Row Limit parameter to be configured to invalid values when none of the other config parameters are set.

---

Feature changes 

None

---

Migration 

None

 

 

---

 

Back to contents

3.2.11.1 interim fix 5

Known Issues 

None

---

Feature changes 

None

---

Migration 

None

 

 

---

 

Back to contents

3.2.11.1 interim fix 4

Known Issues 

None

---

Feature changes 

  
Zelle MANDATE (4/2024)" RDFI "Accept w/o Post" for FRAUD 


When a Zelle payment is received, FTM calls into the Fraud User Exit (UX). If the Fraud UX returns that the inbound payment may be fraudulent (table has DECISION = 2),then FTM updates the EWS payment status with the status of "Accept Without Posting" and awaits for Fraud to send in the proper actimize fraud status (either it is fraudulent or not fraudulent). 

During the wait time the Control Center will show this Inbound Transaction having Status = Held. 

If the actimize fraud status received (in the Zelle inbound queue) specifies that this transaction is fraudulent, then the Inbound Transaction Status changes from Held to Canceled. 

If the actimize fraud status received specifies that this transaction is not fraudulent, then the EWS payment status is updated to Delivered and the Inbound Transaction Status changes from Held to Accepted.

---

Migration 

None

 

 

---

 

Back to contents

3.2.11.1 interim fix 3

Known Issues 

None

---

Feature changes 

None

---

Migration 

None

 

 

---

 

Back to contents

3.2.11.1 interim fix 2

Known Issues 

None

---

Feature changes 

None

---

Migration 

None

 

 

---

 

Back to contents

3.2.11.1 interim fix 1

Known Issues 

None

---

Feature changes 

None

---

Migration 

None

 

---

 

 

Back to contents

3.2.11 Fix pack 1

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

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.11.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.11.1, 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 12
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 8
3.2.9.1	3.2.9.1 interim fix 1
3.2.10.0	3.2.10.0 interim fix 5
3.2.10.1	3.2.10.1 interim fix 2
3.2.10.2	3.2.10.2 interim fix 5
3.2.11.0	3.2.11.0 interim fix 1

 

 

Back to contents

 

---

 

Known issues

 

None

 

Back to contents

---

Feature changes

 

Zelle: Support Multiple EWS Org Ids in a Single Instance of FTM (141760)

 

The initial implementation for Zelle within FTM assumed that the Financial Institution (FI) running FTM would have exactly one organization identifier (Org Id) registered with EWS.  With FI mergers and acquisitions, this single Org Id assumption does not meet the needs of all FTM’s FI customers.

 

Core Property rename/behavior change 
Previously, the FI would set the “Default Zelle Organization ID” core property as the single EWS organization Id representing the FI at EWS.  The “Default Zelle Organization ID” core property has been updated to be a comma-separated list of supported EWS organization Ids that will represent the FI at EWS.  The core property has been renamed “Supported EWS Organization Ids” to reflect the change in behavior.  The first, or only, organization id defined in the core property will be used as the default EWS organization id if/when no organization id has been supplied.

 

 

Transfer Token Screen 
There is also an addition to the “Transfer Token” UI screen to support multiple EWS organizations.  A new “Org Id” dropdown has been added to the screen.  The dropdown will include the EWS organization ids configured in the “Supported EWS Organization Ids” core property.  The dropdown will default to the configured default (first/only organization id in the configured list) organization id.

 

 

General organization Id usage 
Token registration and payment flows should use the EWS participant’s registered organization Id as of today.  Any web service API calls that require any “non-default” organization Ids should include the organization Id in the call to the web service API, which would supersede FTM’s usage of the configured “default” EWS organization Id.

 

HTTP header parameter 
A new key/value HTTP header parameter will be added to every outgoing web service call from FTM to EWS. The key will be "x-ews-org" and the value will be the 3-letter EWS organization Id (Ex. x-ews-org : FGB).   
 

---

 

Zelle: Update to the 4.5 version of the EWS wsdl (141862) 
FTM was upgraded to the 4.5 EWS WSDL for Zelle processing. The RegisterToken4.3 API was upgraded to RegisterToken4.5. The upgrade to the new version of EWS also allows for possible future enhancements without the required WSDL version upgrade. 
 

---

 

Zelle: Fully implement "Token Registration Velocity" using RegisterToken 4.5 (141863) 
The RegisterToken EWS API that FTM uses is being upgraded from RegisterToken4.3 to RegisterToken4.5.  This upgrade allows the correct Token Velocity failure reason (excessive-registration) to be returned from EWS.  With the upgrade to RegisterToken4.5, new possible failure reason codes can be returned from EWS on the RegisterToken API.  These new failure reasons will be returned on CXCToken WS APIs with new numbered return exceptions (included in the Zelle entitled documentation).  The new failure reasons returned from FTM to represent these new failure reasons are: 
  
122265: EWS responded with failure reason code: excessive-registration. 
122266: EWS responded with failure reason code: contact-information-is-invalid. 
122267: EWS responded with failure reason code: token-is-not-available. 
122268: EWS responded with failure reason code: invalid-zelletag-activity.

 

---

 

Zelle: EWS has changed the maximum number of tokens allowed per user from 20 to 5. (142318)

 

Resolution:

1. We defined a new core property for ZELLE that allows the FI to configure the number of tokens that a customer is allowed to register: zel.properties.general.max.registered.token (default value 5).
2. FTM caches this new property and uses the configured value to control the number of tokens allowed for registration.
3. When a participant tries to add a token over the maximum token limit a new error is given: "150300: The maximum number of tokens has been reached".
4. A participant could have up to 2 * the maximum token limit between both Personal and Business.  But, cannot have more than the max of either one in particular.

 

---

 

Zelle: EWS added the new Risk evaluation property. (139743)

 

Resolution:

• Configuration and startup changes. 
  • A new core property was defined in DB CORE_PROPERTIES table under zel.properties.general.ews.risk.evals to store the configured EWS Risk evaluation property.
  • New logic was added to FTM in the Zelle UI EJB startup so that the new EWS Risk evaluation property is properly loaded into the Zelle cache for use by the application.

           After the core property is updated, this requires a restart of the Zelle UI EJB.

 

• API changes. 
  • If Risk evaluations have been configured in FTM and no Risk evaluations have been passed in on the FTM API, then the FTM configured evaluations are passed to EWS and the Fraud UX.
  • If Risk evaluations have been configured in FTM and Risk evaluations have been passed in on the FTM API, then the API provided evaluations take precedence.
  • If Risk evaluations have not been configured in FTM, then the current processing of the API supplied values remains as-is.

 

---

 

Zelle documentation updates 
The Zelle documentation that is included in the entitled documentation fix pack was updated. The link to use to get the entitled documentation fix pack is in the Product documentation section.

 

 

Back to contents

3.2.11.0 interim fix 2

Known Issues 

None

---

Feature changes 

None

 

 

Back to contents

3.2.11.0 interim fix 1

Known Issues 

None

---

Feature changes 

None

 

 

Back to contents

3.2.11

 

 

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.11.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.11.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.11.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 10
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 7
3.2.9.1	3.2.9.1 interim fix 1
3.2.10.0	3.2.10.0 interim fix 4 (except TS010987183)
3.2.10.1	3.2.10.1 interim fix 2

 

 

Back to contents

 

---

 

Known issues

 

• WebSphere Application Server 9.0.5.x Java issue

 

Potential issues were observed when FTM PFS components were deployed on WebSphere Application Server and the most recent (as of 3.2.11.0 release) IBM SDK, Java Technology Edition, Version 8.0.7.16 in combination with WebSphere Application Server 9.0.5.11. 

This issue might happen if you are using IBM Installation Manager, which always points you to the latest available version, to upgrade the middleware stack. For that reason, consider using the following combination: 
IBM WebSphere Application Server Network Deployment 9.0.5.11 
IBM SDK, Java Technology Edition, Version 8.0.7.11

 

• 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\v3211\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

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.

 

 

• Defect 142346: The RFP message currently has a limitation in acknowledging remittance data like RfrdDocAmt

For remittance data to be detected, an empty RfrdDocInf element needs to be provided. For example,

                                <RmtInf>
                                      <Strd>
                                         <RfrdDocInf/>
                                         <RfrdDocAmt>
                                            <DscntApldAmt>
                                               <Tp>
                                                  <Prtry>DSCT</Prtry>
                                               </Tp>
                                               <Amt Ccy=\"USD\">4.23</Amt>
                                            </DscntApldAmt>
                                         </RfrdDocAmt>
                                      </Strd>
                                </RmtInf>

 

Back to contents

 

---

Feature changes

Risk Management: Add velocity limit capability

 

In this release, velocity limit capabilities were added to Risk Management. A velocity limit is a limit on the number of transactions or the dollar amount of the transactions a participant can make within a specified period to prevent fraud, denial of service, or other similar situations. Velocity limits are only for transactions. The maximum time frame for a velocity limit is 24 hours or 1440 minutes. A velocity limit monitor works like the existing risk monitors. The velocity monitors have new fields for counts for credit and debit. The velocity monitor functions like any existing risk monitors and has participant overrides.

Risk Transaction monitor configuration no longer allows -1 as a value for the credit and debit limits. Existing configurations continue to work but require modifications when they are being updated.

The Global Limit Monitor and Participant Limit Monitor user interface was updated to show and configure the velocity limit monitor.

---

 

 

Auto open/activate business days and send an alert if no active business day for real-time payments

To ingest work into FTM, it must be assigned to an existing business day. A business day can be opened and activated in multiple ways: 
- Manually open and activate a business day by using the Manage the Business Days user interface. 
- Under Payment Feature Services Properties, specify true for the Auto Open Business Days property, to automatically open a business day when work is ingested. 
- Use the com.ibm.paydir.izg.tasks.bday.BDayActivationTask in Services Framework to open, activate, or open and activate a business day. 

A fourth way to automatically activate a business day is based on the payment scheme. When Auto Open Business Days is set to true, the configuration specified on the Business Day Actions user interface allows the user to specify to not only automatically open a business day, but to also activate that business day when it is automatically created upon ingestion. The Configuration->Inbound->Automatic Business Day Actions menu option allows the user to create, update, and delete the automatic business day action for each payment scheme. The following screen capture shows the user interface for creating an action.

 

 

Financial institutions processing Real Time Payments (RTP) through FTM should use the Services Framework task to automatically activate business days, but can use this feature as a backup in case the configuration is incorrect or an error occurs. When this feature is used, RTPs might encounter an issue where the RTP transaction is assigned to an FTM business day that was not activated. The processing of the RTP transaction either times out or is rejected waiting on the defined workflow to execute because the inactive business day does not allow the downstream processing (Risk, and others) to occur.

To receive an alert if a payment is received and no active business day exists, the payment must be associated with a payment scheme that is identified as being a real-time payment. A new column, IS_RTP was added to the PAYMENT_SCHEME_TYPE table, which is loaded as part of the DSU. 

The SampleBusinessRulesAchConfiguration spreadsheets were modified for the TCH, Zelle, and Wire Business Rules workflows to assign a specific error code when a payment is assigned to a nonactive business day.

---

 

File names for NACHA files

The created timestamp of the outbound transmission was used as the substitution value for the "%DT%" portion of file name pattern for NACHA files. This timestamp reflects the time that the outbound transmission hierarchy is created in the database rather than the current time of transmission generation. Some customers want to use the current time of transmission generation. 

A new configuration parameter was added to the transmission definition called: Current Time for file name DT Pattern. When this parameter is set to Yes, the current time of transmission generation is used as the time value for the DT file name substitution token. When it is set to No, the created time is used. This parameter applies to all payment types.

 

---

 

Assorted improvements on the graphical user interface

 

System Overview page: Provide missing support for Risk Engine authorization and blocking filters that suspend transactions

A new field was added to the System Overview page to track remaining risk authorization work left to be handled. The field is a link to Risk Review > Authorization and a Business Date range filter is automatically applied to match the configured System Overview filter.

 

Task Activity: Add "Are you sure" prompt when the restart icon is clicked

On the Task Activity page, the restart task action now has an extra prompt to confirm that the user intended to restart the task. This prompt was added as an extra layer of protection to keep the user from accidentally restarting long running tasks when they are viewing the task details.

 

Returns: A dialog box was added to confirm manual returns when the return violates the CPA and NACHA rules for time limits for returns

An extra warning message is shown when the manual return process is started and any one of the transactions that are to be returned is outside the return window. The user can cancel the return process from the dialog box if they want to. The return window type and the return windows are defined in the REASON_CODE_RETURN_XREF table, which can be configured by using the data setup utility (DSU).

 

Participant directory: Originator > Authorized Destinations support

A new preference was added to the participant directory to manage participants authorized to receive transmissions (destinations) from a selected participant. 
Preference: Participant Directory -> Originator -> Authorized Destinations. 
Note: This preference page is available only when the selected participant is assigned the role of originator under General > Roles.

---

 

Clean up obsolete SOAP web services

 

The following SOAP-based web services were removed: 
AddControlTotalRequest - Replaced by the WebSphere Application Server Liberty RESTful web service POST /controltotal as documented in openapi-gateway-3.2.11.yaml. 
ListMessageStandardsRequest - Replaced by the WebSphere Application Server RESTful web service GET /messagestandards as documented in swagger-3.2.11.json. 
UserEntitlementsRequest - No replacement is available currently. 

The SOAP-based web services client sample application was also removed because the last remaining sample demonstrated the AddControlTotalRequest web service, which was removed. Customers need to manually remove the WebServicesClient_EAR application from all WebSphere Application Server deployments.

 

Back to contents