Fix Readme
Abstract
This document contains V3.2.3 release information for Financial Transaction Manager for Digital Payments for Multiplatforms.
Content
Financial Transaction Manager for Digital Payments V3.2.3 Release Information
Contents
Common Across Releases
3.2.3.0 Release
... 3.2.3.0 interim fix 1
... 3.2.3.0 interim fix 2
... 3.2.3.0 interim fix 2.1
... 3.2.3.0 interim fix 2.2
... 3.2.3.0 interim fix 3
... 3.2.3.0 interim fix 4
... 3.2.3.0 interim fix 4.1
... 3.2.3.0 interim fix 5
... 3.2.3.0 interim fix 6
When upgrading a fix pack or interim fix, in addition to the changes in the level that is being upgraded to, be sure to review the changes in the intermediate fix packs or interim fixes.
Examples:
- Currently at level fix pack 1 and upgrading to level fix pack 3, review the changes in fix pack 2 and fix pack 3.
- Currently at fix pack 1 / interim fix 1 and upgrading to fix pack 1 / interim fix 3, review the changes in fix pack 1 / interim fix 2 and fix pack 1 / interim fix 3.
| Back to top |
Common Across Releases
|
Known Issues
None.
Feature changes
Data Setup Utility
The following documentation describes the changes for the data setup utility (DSU) and the import and export workbooks:
DSUmigration_v3.2.3.pdf
DSUMigrationBR_v3.2.3.pdf
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
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.3.pdf
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
General Instructions
Installation
- Start IBM Installation Manager.
- Add the location of the repository that contains the installation package:
- Select File > Preferences.
- Click Add Repository.
- Browse to the directory that contains the repository .zip file and select the file. Click Open and then OK.
- Click Test Connections and then OK.
- Click OK.
- Install the FTM product installation files to your installation directory:
- On the main pane, click Update.
- Select IBM Financial Transaction Manager for Digital Payments, IBM Financial Transaction Manager for Check Services, or IBM Financial Transaction Manager for Corporate Payment Services and then click Next.
- Select the fix pack or interim fix and then click Next.
- Follow the rest of the prompts.
- Confirm that the "Update packages" page shows success.
Deployment
- Do the database migration. Refer to the Database migration section in this document.
- Note: The runtime components can’t be running during the database migration.
- Note: Files can continue to be delivered to the Gateway inbound source folder.
- J2SE components: The installation overlays the J2SE applications, so no special migration instructions are needed. Restarting those applications updates them with the fixes.
- WebSphere Application Server (WAS) components: You can use the Automated Deployment Utility (ADU), manually upgrade (refer to the update instructions in each WAS component doc folder), or, in a WAS Network Deployment configuration, use the Deployment Manager.
- All WebSphere servers must be restarted after all the components were updated.
- 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 WAS profile deployment. If you are using a new WAS 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.
- Update your Transaction Server Scheduler.xml. Refer to the Transaction Server Scheduler XML section in this document. Note: Updating the scheduler file might not be required for your installation.
- Refer to the release-specific section for any changes that might affect your installation.
- Start your runtime components.
- 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.
| Back to top |
3.2.3.0 interim fix 5
|
Known Issues
116802 (fixed at this interim fix level with the information provided below)
Distribution changes to help with performance of 1k batch
Use the following file to add the property:
3.2.3.0.ifix5.116802.ddl
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
116802 (fixed at this interim fix level with the information provided below)
Distribution changes to help with performance of 1k batch
Use the following file to add the property:
3.2.3.0.ifix5.116802.ddl
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
Feature changes
None.
None.
Migration
None.
None.
| Back to top |
3.2.3.0 interim fix 4.1
|
Known Issues
None.
None.
Feature changes
None.
None.
Migration
None.
None.
| Back to top |
3.2.3.0 interim fix 4
|
Known Issues
None.
None.
Feature changes
None.
None.
Migration
None.
None.
| Back to top |
3.2.3.0 interim fix 3
|
Known Issues
None.
None.
Feature changes
None.
None.
Migration
None.
None.
| Back to top |
3.2.3.0 interim fix 2.2
|
Known Issues
None.
None.
Feature changes
None.
None.
Migration
None.
None.
| Back to top |
3.2.3.0 interim fix 2.1
|
Known Issues
None.
None.
Feature changes
None.
None.
Migration
None.
None.
| Back to top |
3.2.3.0 interim fix 2
|
Known Issues
111502 (fixed at this interim fix level with the information provided below)
PERF Tuning Index for query that is consuming a lot of CPU
Use the following file to create the index:
3.2.3.0.ifix2.111502.ddl
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
111502 (fixed at this interim fix level with the information provided below)
PERF Tuning Index for query that is consuming a lot of CPU
Use the following file to create the index:
3.2.3.0.ifix2.111502.ddl
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
Feature changes
None.
None.
Migration
None.
None.
| Back to top |
3.2.3.0 interim fix 1
|
Known Issues
None.
None.
Feature changes
None.
None.
Migration
Refer to the following document for migration details:
DSUMigrationBR_v3.2.3.pdf
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
Refer to the following document for migration details:
DSUMigrationBR_v3.2.3.pdf
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
| Back to top |
3.2.3.0 Release
|
Compatibility Matrix
Because the development of releases and interim fixes (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 you which releases and interim fix levels can be successfully upgraded to V3.2.3.
In the following table, the "If you're on version" column shows you the releases that can be upgraded successfully. The highest release or interim fix level that can be upgraded for each release is shown in the "To successfully upgrade to V3.2.3, you must be no higher than version" column. If the release that you are upgrading from is at an interim fix level that is higher than the release or fix level that is 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.
Because the development of releases and interim fixes (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 you which releases and interim fix levels can be successfully upgraded to V3.2.3.
In the following table, the "If you're on version" column shows you the releases that can be upgraded successfully. The highest release or interim fix level that can be upgraded for each release is shown in the "To successfully upgrade to V3.2.3, you must be no higher than version" column. If the release that you are upgrading from is at an interim fix level that is higher than the release or fix level that is 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 V3.2.3, you must be no higher than version |
| 3.2.2.1 | 3.2.2.1 interim fix 1 |
Known Issues
None.
Feature changes
97835
Respond to request for Information from an FI
This delivery includes the required changes for the TCH 2.9 release related to the camt.026 (Request for Information) and camt.028 (Response to Request for Information) messages.
FTM for Digital Payments can now respond to requests for information from the FTM Digital Payments UI with the 'Send Information' action on the Inbound Transaction screen under More > Actions.
FTM for Digital Payments can now initiate a request for information against a request for payment on the FTM Digital Payments UI on the Inbound Transaction screen under More > Actions.
The following changes apply to initiating a Request for Information from a webservice or from the FTM Digital Payments UI 'Request Information' action for a payment or payment request.
FTM for Digital Payments can now respond to requests for information from the FTM Digital Payments UI with the 'Send Information' action on the Inbound Transaction screen under More > Actions.
FTM for Digital Payments can now initiate a request for information against a request for payment on the FTM Digital Payments UI on the Inbound Transaction screen under More > Actions.
The following changes apply to initiating a Request for Information from a webservice or from the FTM Digital Payments UI 'Request Information' action for a payment or payment request.
- When initiating a Request for Information you can now select Financial Institution or Customer to be the request's initiator type.
- When initiating a Request for Information you can now use two additional reason codes - Incorrect Requested Execution Date and Incorrect Instruction For Creditor Agent.
Functional changes include:
- The Request for Information may now relate to either a Payment or a Request for Payment.
- The Request for Information message (camt.026) may contain some additional codes (IN04, IN19) relating to incorrect information in the original message.
- The Request for information can be sent by (or on behalf of) a Participant’s customer, or by a Participant. The receiving Participant of the RFI should present it to their customer if the RFI was sent by a customer, and they should present it to an employee of the Participant if the RFI was sent by a Participant(and also similar for Response to RFI).
- To satisfy the above function, UI support to initiate a Response to Request for Information was added.
93785
Support change to camt.056 messages for spec 2.9
Support change to camt.056 messages for spec 2.9
This delivery includes support in FTM for Digital Payments for changes to the camt.056 message in the TCH RTP 2.9 message specifications. These include a new option to 'Expire' an outgoing pain.013 (Request for Payment), which will generate a corresponding camt.056. It also introduces the option to specify whether it is a customer or an FI that is initiating the expiry or request for return of funds.
Functional changes include:
- Use of camt.056 as a Request for Payment Expiry message.
- Updated list of cancellation reason codes.
- Addition of new proprietary reason codes that the sender can offer, that are configured through the DSU.
93784
Support changes to camt.029 message for spec 2.9
Support changes to camt.029 message for spec 2.9
This delivery includes support in FTM for Digital Payments for changes to the camt.029 message in the TCH RTP 2.9 message specifications. These include specifying the amount to charge when accepting a camt.056 message and returning funds, as well as a new option to return outside of the RTP network, which allows the user to specify the clearing channel they wish to use to return the funds.
The main functional changes are:
- The camt.056 message can now be used to cancel an outstanding Request for Payment.
- The Request for Return of Funds (camt.056) message has been extended to allow additional cancellation reason codes.
- For the cancellation originator, either the name (if initiated by customer), or Member Id (if initiated by participant), must be provided, but not both as previously allowed.
- The Response to Request for Return of Funds (camt.029) message allows an additional confirmation code to indicate that a partial refund will be made. It also includes elements to provide details on the amount, charges, settlement date, and clearing channel for the refund.
To return a payment via a Non-TCH rail, Set the following core property to false: Return Payment via the TCH rail. This property is located in Administration -> Components -> TCH -> Properties."
93782
Support new pacs.009 Inbound/Outbound
Support new pacs.009 Inbound/Outbound
This delivery includes support in FTM for Digital Payments for the TCH 2.9 release related to the pacs.009 message, which is a FI to FI credit transfer and processes similarly to the pacs.008 message. The pacs.009 message is being introduced to allow participants to send and receive additional liquidity, as necessary, during hours when Fedwire is unavailable.
The main functional changes are:
- A limit check is not required for the transaction amount. Separate sets of configurable services are required.
- The pacs.009 message does not contain Debtor Agent or Creditor Agent, the Debtor and Creditor represent the FIs that manage the accounts.
- There is no Return variant of the pacs.009.
- The ACWP response does not apply for FI to FI Credit Transfer (this is not stated in the TCH documentation but implied from the description of the ACWP code and the camt.035 message).
- The non-payment messages that may relate to a pacs.008 (Request for Return of Funds, Request for information, Payment Acknowledgement, etc.) do not apply for the FI to FI Credit Transfer (This is not stated in the TCH documentation but implied based on the schema for camt.056 & camt.026 and the camt.035 message description.)
87856
v2.9 Spec Update - discounted amount fields
This delivery includes support for the new fields added for the TCH Spec 2.9. discounted amount field(s) for pacs.008 and pain.013 messages.
This includes the usage within applicable raw data views and webservice calls.
This includes the usage within applicable raw data views and webservice calls.
Functional changes include:
- pacs.008 inbound mappers
- pain.013 inbound & outbound mappers
87855
v2.9 Spec Update - secure token exchange
v2.9 Spec Update - secure token exchange
With TCH Spec 2.9 it is now possible for TCH to send an acmt.022 Token Notification Message to the originator for pacs.008 and pain.013 messages if the recipient has signed up for TCH's Secure Token Exchange. If an acmt.022 message is received, the system will attempt to update the participant's (originator) recipient entry with the token account and token bank code that was provided in the acmt.022 message.
TCH sends an acmt.022 message to the Debtor FI / Creditor FI to send a tokenized Routing and Transit number and account number back to the sender of a Credit Transfer or a Request for Payment when the sender of the pacs.008 or pain.013 used account credentials is in the clear and a token exists in the token service for the recipient account.
88214
Expand "Scheduled Payments" to include TCH Real Time Payments
Expand "Scheduled Payments" to include TCH Real Time Payments
This delivery includes UI support for TCH RTP within the FTM for Digital Payments Scheduled Payments screen. Web services for Scheduled Payments are referred to as Recurring Payments.
The Scheduled Payments screen includes:
- Grid display of all the Scheduled Payments in the system.
- Ability to view a single Scheduled Payment with full details in tabular form when clicked on the Model name.
- Ability to Update the Scheduled Payment (both active and non-active).
- Ability to Cancel the model or Cancel the next scheduled payment via action buttons on the Grid.
- Create is ONLY available via RESTful Web service.
Limitation: DSU export/import from one system to another is not yet supported.
97349
Include Origin Name as part of Gateway Duplicate detection for file
Gateway File Duplicate detection has been enhanced to include Origin Name from the ACH File Header Record (64:23) as part of duplicate detection criteria.
Include Origin Name as part of Gateway Duplicate detection for file
Gateway File Duplicate detection has been enhanced to include Origin Name from the ACH File Header Record (64:23) as part of duplicate detection criteria.
102494
Create the ability to filter the participant grid by Zelle token
A new Tokens column has been added to the Participant Directory grid. This column will not be displayed by default, but can be added to the grid.
This column will display any payment tokens (currently only Zelle tokens) that are associated with the participant. The column will contain a comma separated list of tokens associated with the participant.
This column can be filtered and will be included in the quick search capability of the participant grid.
Create the ability to filter the participant grid by Zelle token
A new Tokens column has been added to the Participant Directory grid. This column will not be displayed by default, but can be added to the grid.
This column will display any payment tokens (currently only Zelle tokens) that are associated with the participant. The column will contain a comma separated list of tokens associated with the participant.
This column can be filtered and will be included in the quick search capability of the participant grid.
88137, 88138
Participant Directory Preference screens for Zelle Participants
The FTM participant’s that are EWS/Zelle participants are now integrated into FTM’s participant directory. Each of these participants will be assigned a Zelle Participant Role. This role designation will allow the Zelle participants to be distinctly identified within the participant directory grid and it will allow the Zelle participant preference (and child preferences) details to be seen within the participant’s details.
On the participant directory grid, the user can optionally configure the grid to include the “Zelle Participant” role as a viewable column. (*Note: The Zelle Participant role column is not displayed by default. It can be added within the table configuration options for the grid.)
When viewable the user can use the column to filter on those participant’s that are Zelle Participants.
When viewing an FTM participant’s details, the role preferences that the user has permission to view are listed in the left-hand window. For Zelle Participants, there is now a viewable preference. When the user selects the Zelle Participant preference, the following screen will be displayed.
A Zelle participant also has Tokens that can be configured. The Zelle Tokens will appear as a “child” preference of the Zelle Participant. A Zelle Participant is considered to be an “operational” preference. An operational preference is a non-versioned preference, so any changes made to operational preferences will occur immediately in the system.
A Zelle participant can have multiple tokens, so the tokens preference will display a configurable grid that displays the tokens that have been configured for the selected Zelle Participant. This grid will have (permissionable) row level actions that can be executed on each token. The available actions are:
• View Token History – Provides a popup that displays the EWS history of the token
• Deactivate Token
• Restrict Token
• Unrestrict Token
Since the Zelle tokens preference is an operations/non-versioned preference, the latter 3 actions will only be available on the current active version of the participant. This is to try and make clear that any changes made to an operational preference take effect immediately (current active).
A sample tokens grid with the available row level actions can be seen here.
When one of the token actions (deactivate, restrict, unrestrict) are selected, the user will be shown a confirmation window that describes the action being taken. The user will then confirm whether to continue the selected action.
An example token deactivation confirmation:
The restrict token and unrestrict token confirmations allow the user to input an optional reason for the action.
An example token restriction confirmation:
An example token unrestriction confirmation:
A Zelle participant can have multiple recipients, so the recipients preference will display a configurable grid that displays the recipients that have been configured for the selected Zelle Participant. This grid does not have any row level actions available.
A sample recipient's grid can be seen here.
In order to view and/or take actions on the Zelle Participant, Tokens and Recipients preferences, the user must have the correct permissions. Those permissions can be seen here:
Since tokens and recipients are child preferences of a Zelle Participant, those preferences cannot be reached unless the user has permission to view the Zelle Participant.
To successfully perform any EWS related functions (deactivate, restrict, unrestrict, etc.), the correct webservice client bindings need to be configured in the Websphere Administrative Console for the coreui_ejbear. This configuration is the same setting that is done for the RTPUIEJB_EAR. It is assumed that these settings would be the same. However, that is not a prerequisite for FTM. The coreui_ejbear configuration setting can be seen here:
User Exit updates
Since Zelle/EWS related API calls are being executed from the core UI, a more generic exception needed to be thrown and handled product wide. So, the com.ibm.fxh.zel.ui.ejb.cxcservice.CXCServiceException class was renamed to com.ibm.fxh.zel.communication.ZelleServiceException.
When existing user exits are recompiled with 3.2.3 level jar files, and compile errors occur because of a missing com.ibm.fxh.zel.ui.ejb.cxcservice.CXCServiceException class, then that class should be updated to com.ibm.fxh.zel.communication.ZelleServiceException.
Participant Directory Preference screens for Zelle Participants
The FTM participant’s that are EWS/Zelle participants are now integrated into FTM’s participant directory. Each of these participants will be assigned a Zelle Participant Role. This role designation will allow the Zelle participants to be distinctly identified within the participant directory grid and it will allow the Zelle participant preference (and child preferences) details to be seen within the participant’s details.
On the participant directory grid, the user can optionally configure the grid to include the “Zelle Participant” role as a viewable column. (*Note: The Zelle Participant role column is not displayed by default. It can be added within the table configuration options for the grid.)
When viewable the user can use the column to filter on those participant’s that are Zelle Participants.
When viewing an FTM participant’s details, the role preferences that the user has permission to view are listed in the left-hand window. For Zelle Participants, there is now a viewable preference. When the user selects the Zelle Participant preference, the following screen will be displayed.
A Zelle participant also has Tokens that can be configured. The Zelle Tokens will appear as a “child” preference of the Zelle Participant. A Zelle Participant is considered to be an “operational” preference. An operational preference is a non-versioned preference, so any changes made to operational preferences will occur immediately in the system.
A Zelle participant can have multiple tokens, so the tokens preference will display a configurable grid that displays the tokens that have been configured for the selected Zelle Participant. This grid will have (permissionable) row level actions that can be executed on each token. The available actions are:
• View Token History – Provides a popup that displays the EWS history of the token
• Deactivate Token
• Restrict Token
• Unrestrict Token
Since the Zelle tokens preference is an operations/non-versioned preference, the latter 3 actions will only be available on the current active version of the participant. This is to try and make clear that any changes made to an operational preference take effect immediately (current active).
A sample tokens grid with the available row level actions can be seen here.
When one of the token actions (deactivate, restrict, unrestrict) are selected, the user will be shown a confirmation window that describes the action being taken. The user will then confirm whether to continue the selected action.
An example token deactivation confirmation:
The restrict token and unrestrict token confirmations allow the user to input an optional reason for the action.
An example token restriction confirmation:
An example token unrestriction confirmation:
A Zelle participant can have multiple recipients, so the recipients preference will display a configurable grid that displays the recipients that have been configured for the selected Zelle Participant. This grid does not have any row level actions available.
A sample recipient's grid can be seen here.
In order to view and/or take actions on the Zelle Participant, Tokens and Recipients preferences, the user must have the correct permissions. Those permissions can be seen here:
Since tokens and recipients are child preferences of a Zelle Participant, those preferences cannot be reached unless the user has permission to view the Zelle Participant.
To successfully perform any EWS related functions (deactivate, restrict, unrestrict, etc.), the correct webservice client bindings need to be configured in the Websphere Administrative Console for the coreui_ejbear. This configuration is the same setting that is done for the RTPUIEJB_EAR. It is assumed that these settings would be the same. However, that is not a prerequisite for FTM. The coreui_ejbear configuration setting can be seen here:
User Exit updates
Since Zelle/EWS related API calls are being executed from the core UI, a more generic exception needed to be thrown and handled product wide. So, the com.ibm.fxh.zel.ui.ejb.cxcservice.CXCServiceException class was renamed to com.ibm.fxh.zel.communication.ZelleServiceException.
When existing user exits are recompiled with 3.2.3 level jar files, and compile errors occur because of a missing com.ibm.fxh.zel.ui.ejb.cxcservice.CXCServiceException class, then that class should be updated to com.ibm.fxh.zel.communication.ZelleServiceException.
88152
Zelle Organization Participant Directory screen
The FTM participant’s that are EWS/Zelle organizations are now integrated into FTM’s participant directory. Each of these participants will be assigned a Zelle Organization Role. This role designation will allow the Zelle organizations to be distinctly identified within the participant directory grid and it will allow the Zelle organization preference details to be seen within the participant’s details.
On the participant directory grid, the user can optionally configure the grid to include “Zelle Organization” role as a viewable column. (*Note: The Zelle Organization role column is not displayed by default. It can be added within the table configuration options for the grid.)
When viewable the user can use the column to filter on those participant’s that are Zelle Organizations.
When viewing an FTM participant’s details, the role preferences that the user has permission to view are listed in the left-hand window. For Zelle Organizations, there is now a viewable preference. When the user selects the Zelle Organization preference, the following screen will be displayed.
In order to view the Zelle Organization preference, the user must have the correct permission. That permission can be seen here:
Zelle Organization Participant Directory screen
The FTM participant’s that are EWS/Zelle organizations are now integrated into FTM’s participant directory. Each of these participants will be assigned a Zelle Organization Role. This role designation will allow the Zelle organizations to be distinctly identified within the participant directory grid and it will allow the Zelle organization preference details to be seen within the participant’s details.
On the participant directory grid, the user can optionally configure the grid to include “Zelle Organization” role as a viewable column. (*Note: The Zelle Organization role column is not displayed by default. It can be added within the table configuration options for the grid.)
When viewable the user can use the column to filter on those participant’s that are Zelle Organizations.
When viewing an FTM participant’s details, the role preferences that the user has permission to view are listed in the left-hand window. For Zelle Organizations, there is now a viewable preference. When the user selects the Zelle Organization preference, the following screen will be displayed.
In order to view the Zelle Organization preference, the user must have the correct permission. That permission can be seen here:
88154
Zelle Participant Grid and Participant Directory enhancements
The FTM participant grid has been enhanced to include participants that are Zelle participants and Zelle organizations. New functions have been added to the participant directory grid to allow for ease of use of Zelle related and other functions. New roles have been created to clearly define those participants that are Zelle Participants and Zelle Organizations. These roles will allow the user to filter on those participants that have been assigned those roles. There has also been a new Tokens column added to the participant directory grid. This will allow a user to search on a participant’s token on the participant directory grid. (*Note: None of the above columns are displayed by default but can be added to the grid by configuring the table.) A sample participant directory grid (filtered on Zelle Participants) with the new columns displayed can be seen here:
New row level actions have been added to the participant directory grid. The new actions include:
• Limit Monitors – When selected takes the user to the selected participant’s Risk monitors screen
• Deactivate Zelle Participant – Only available for participants with the Zelle Participant role assigned
• Restrict Zelle Participant– Only available for participants with the Zelle Participant role assigned
• Unrestrict Zelle Participant– Only available for participants with the Zelle Participant role assigned
Each of the new row level actions are only permissioned and will only be allowed when the user has the correct permissions. The Zelle related action permissions can be seen here:
The Limit Monitor action will be allowed if the user has permission to view the Risk activity monitors.
Selecting each of the Zelle related actions will display a dialog window to clearly describe the action that is being taken and to ensure the user wants to execute the action.
Deactivate Zelle Participant
Restrict Zelle Participant
This dialog will allow the user to include the reason why the participant is being restricted.
Unrestrict Zelle Participant
This dialog will allow the user to include the reason why the participant is being unrestricted.
To successfully perform any EWS related functions (deactivate, restrict, unrestrict, etc.), the correct webservice client bindings need to be configured in the Websphere Administrative Console for the coreui_ejbear. This configuration is the same setting that is done for the RTPUIEJB_EAR. It is assumed that these settings would be the same. However, that is not a prerequisite for FTM. The coreui_ejbear configuration setting can be seen here:
Zelle Participant Grid and Participant Directory enhancements
The FTM participant grid has been enhanced to include participants that are Zelle participants and Zelle organizations. New functions have been added to the participant directory grid to allow for ease of use of Zelle related and other functions. New roles have been created to clearly define those participants that are Zelle Participants and Zelle Organizations. These roles will allow the user to filter on those participants that have been assigned those roles. There has also been a new Tokens column added to the participant directory grid. This will allow a user to search on a participant’s token on the participant directory grid. (*Note: None of the above columns are displayed by default but can be added to the grid by configuring the table.) A sample participant directory grid (filtered on Zelle Participants) with the new columns displayed can be seen here:
New row level actions have been added to the participant directory grid. The new actions include:
• Limit Monitors – When selected takes the user to the selected participant’s Risk monitors screen
• Deactivate Zelle Participant – Only available for participants with the Zelle Participant role assigned
• Restrict Zelle Participant– Only available for participants with the Zelle Participant role assigned
• Unrestrict Zelle Participant– Only available for participants with the Zelle Participant role assigned
Each of the new row level actions are only permissioned and will only be allowed when the user has the correct permissions. The Zelle related action permissions can be seen here:
The Limit Monitor action will be allowed if the user has permission to view the Risk activity monitors.
Selecting each of the Zelle related actions will display a dialog window to clearly describe the action that is being taken and to ensure the user wants to execute the action.
Deactivate Zelle Participant
Restrict Zelle Participant
This dialog will allow the user to include the reason why the participant is being restricted.
Unrestrict Zelle Participant
This dialog will allow the user to include the reason why the participant is being unrestricted.
To successfully perform any EWS related functions (deactivate, restrict, unrestrict, etc.), the correct webservice client bindings need to be configured in the Websphere Administrative Console for the coreui_ejbear. This configuration is the same setting that is done for the RTPUIEJB_EAR. It is assumed that these settings would be the same. However, that is not a prerequisite for FTM. The coreui_ejbear configuration setting can be seen here:
97419
Operational participant versioning
Most of the Participant Directory preferences are all versioned. The versioning concept allows users of the system to stage participants and have various participant updates in an “edit” state that would not affect the current operation of the system. There is some overhead to this approach. Whenever a new version is created, an entire copy of the previous version and its preferences are copied into a new editable version of the participant.
With the introduction of Zelle, it was determined that mobile application users could significantly increase the amount of participant version data stored just by performing day to day operations like adding/updating tokens and recipients. In order to eliminate this issue, some participant preferences will now be treated as “operational”/non-versioned preferences. Any changes to these preferences will be immediate. The operation preferences are considered to be end user centric where those users will be making frequent updates to the stored participant preference. The current preferences that are treated as operational preferences are:
The operational preferences will be displayed in the preferences tree along with the versioned preferences. The operational preferences will be displayed with a special operational indicator to allow the user to determine the differences. The total number of operational preferences will be included in the footer of the screen. Here is an example preference tree:
The preference detail screen for each operational preference will highlight the fact that it is an operational preference in its banner.
Operational participant versioning
Most of the Participant Directory preferences are all versioned. The versioning concept allows users of the system to stage participants and have various participant updates in an “edit” state that would not affect the current operation of the system. There is some overhead to this approach. Whenever a new version is created, an entire copy of the previous version and its preferences are copied into a new editable version of the participant.
With the introduction of Zelle, it was determined that mobile application users could significantly increase the amount of participant version data stored just by performing day to day operations like adding/updating tokens and recipients. In order to eliminate this issue, some participant preferences will now be treated as “operational”/non-versioned preferences. Any changes to these preferences will be immediate. The operation preferences are considered to be end user centric where those users will be making frequent updates to the stored participant preference. The current preferences that are treated as operational preferences are:
- Zelle Participant
- Tokens
- Recipients
- Originator
- Scheduled Payments
The operational preferences will be displayed in the preferences tree along with the versioned preferences. The operational preferences will be displayed with a special operational indicator to allow the user to determine the differences. The total number of operational preferences will be included in the footer of the screen. Here is an example preference tree:
The preference detail screen for each operational preference will highlight the fact that it is an operational preference in its banner.
98703
Update threading model for Zelle payments
The Zelle application has to provide synchronous webservice responses while using internal asynchronous process to generate the FTM payment and process the payment through the various processing flows (Risk, etc.). In 3.0.6.x releases of FTM, the Zelle application had to wait for Gateway and Risk to process the payment. This was a static process and made use of putting processing threads to sleep while waiting for the asynchronous processes to complete. This architecture does not fit into FTM’s workflow model that allows customers to dictate the workflows of their payment processing.
In FTM 3.2.3, this process has been changed to allow for callback queue to be monitored that will notify the Zelle application when the Zelle payment processing has completed. A new “FXH.ZELLE.COMPLETE.QUEUE” is required. Example WAS MQ declarations:
FTM_AllCommon_en.properties
mq_queueNameBaseFxhZelleCompleteQueue=WMQ Zelle Complete Queue
mq_queueNameBaseFxhZelleCompleteQueue_helpText=Zelle MQ queue for FTM Zelle processing complete messages<br/><br/>Example: FXH.ZELLE.COMPLETE.QUEUE
FTM_AllCommon.cfg
<parameter type="text" isRequired="true">
<id>mq_queueNameBaseFxhZelleCompleteQueue</id>
<defaultValue>FXH.ZELLE.COMPLETE.QUEUE</defaultValue>
</parameter>
FTM_ZEL_Console.cfg
<setting type='wsadmin' command='CreateQueue'>
<arg type='varSub'>${common,mq,mq_queueNameBaseFxhZelleCompleteQueue}</arg>
<arg type='varSub'>${common,mq,channelName}</arg>
<arg type='String'>jms/Zelle/ZelleCompleteQ</arg>
<arg type='String'>WebSphere MQ Input Queue for FTM Zelle processing complete messages</arg>
</setting>
…
<setting type='wsadmin' command='CreateListenerPort'>
<arg type='String'>ZEL Complete Main Listener Port</arg>
<arg type='String'>jms/Zelle/ZelleQCF</arg>
<arg type='String'>jms/Zelle/ZelleCompleteQ</arg>
<arg type='String'>Listener port for Zelle processing complete messages</arg>
</setting>
…
<setting type='wsadmin' command='RemoveQueueUtility'>
<arg type='String'>jms/Zelle/ZelleCompleteQ</arg>
</setting>
After creating a new placeholder batch for the Zelle payment, the new Zelle payment processing will use the generated batch id as a message selector and will monitor the new Zelle complete queue the message selector of the generated batch. When a message appears on the Zelle complete queue, that will signify to the Zelle application that the FTM payment process workflow has completed. The Zelle application will monitor the Zelle complete queue for the configured payment processing timeout value. If a message has not been received by the configured time, then the Zelle application will exit and return a failure to the user. To provide better controls, the Zelle payment processing timeout has been split into 2 different properties(Zelle Outbound Payment Processing Timeout, Zelle Inbound Payment Processing Timeout). These timeouts will be used when monitoring the Zelle complete queue.
For this process to work, the ITS scheduler must have a stanza that represents the “end” of the Zelle payment processing workflow. The new stanza must use the newly created ZelleCompletePresentmentStatesEventHandler. This new handler is based on the batch/presentment states of the Zelle payment.
The scheduler reference maintains the current workflow for both inbound and outbound payments where both Gateway and Risk must be executed for the Zelle payment to be completely processed. However, this can be adjusted (like other workflow processes) to meet the needs of the financial institution. The Scheduler reference contains the following stanza for the new event processor:
<EVENT>
<NAME>Zelle process complete</NAME>
<TYPE>PresentmentStateChange</TYPE>
<TYPE>PresentmentColumnChange</TYPE>
<TYPE>PresentmentGroupColumnChange</TYPE>
<EXEC>com.ibm.paydir.ima.txsvr.event.appbridge.ZelleCompletePresentmentStatesEventHandler</EXEC>
<PARAMETER name="msgType">zelleIngestComplete</PARAMETER>
<PARAMETER name="presStates1">LOADED,AUTH_REVIEWED</PARAMETER>
<PARAMETER name="paymentStandard">ZELLE</PARAMETER>
<PARAMETER name="pending">N</PARAMETER>
<PARAMETER name="group.pending">N</PARAMETER>
<PARAMETER name="presLevel">INB</PARAMETER>
<PARAMETER name="msgExpiryTime">30000</PARAMETER>
<PARAMETERREF>schedulerReferenceProperties</PARAMETERREF>
<PARAMETERREF>sendToZelleComplete</PARAMETERREF>
</EVENT>
<PARAMETERSET name="sendToZelleComplete">
<PARAMETER name="destinationID">Zelle Complete</PARAMETER>
<PARAMETER name="jmsSendQueue">FXH.ZELLE.COMPLETE.QUEUE</PARAMETER>
</PARAMETERSET>
The following sequence diagram shows the new Zelle payments processing flow.
Update threading model for Zelle payments
The Zelle application has to provide synchronous webservice responses while using internal asynchronous process to generate the FTM payment and process the payment through the various processing flows (Risk, etc.). In 3.0.6.x releases of FTM, the Zelle application had to wait for Gateway and Risk to process the payment. This was a static process and made use of putting processing threads to sleep while waiting for the asynchronous processes to complete. This architecture does not fit into FTM’s workflow model that allows customers to dictate the workflows of their payment processing.
In FTM 3.2.3, this process has been changed to allow for callback queue to be monitored that will notify the Zelle application when the Zelle payment processing has completed. A new “FXH.ZELLE.COMPLETE.QUEUE” is required. Example WAS MQ declarations:
FTM_AllCommon_en.properties
mq_queueNameBaseFxhZelleCompleteQueue=WMQ Zelle Complete Queue
mq_queueNameBaseFxhZelleCompleteQueue_helpText=Zelle MQ queue for FTM Zelle processing complete messages<br/><br/>Example: FXH.ZELLE.COMPLETE.QUEUE
FTM_AllCommon.cfg
<parameter type="text" isRequired="true">
<id>mq_queueNameBaseFxhZelleCompleteQueue</id>
<defaultValue>FXH.ZELLE.COMPLETE.QUEUE</defaultValue>
</parameter>
FTM_ZEL_Console.cfg
<setting type='wsadmin' command='CreateQueue'>
<arg type='varSub'>${common,mq,mq_queueNameBaseFxhZelleCompleteQueue}</arg>
<arg type='varSub'>${common,mq,channelName}</arg>
<arg type='String'>jms/Zelle/ZelleCompleteQ</arg>
<arg type='String'>WebSphere MQ Input Queue for FTM Zelle processing complete messages</arg>
</setting>
…
<setting type='wsadmin' command='CreateListenerPort'>
<arg type='String'>ZEL Complete Main Listener Port</arg>
<arg type='String'>jms/Zelle/ZelleQCF</arg>
<arg type='String'>jms/Zelle/ZelleCompleteQ</arg>
<arg type='String'>Listener port for Zelle processing complete messages</arg>
</setting>
…
<setting type='wsadmin' command='RemoveQueueUtility'>
<arg type='String'>jms/Zelle/ZelleCompleteQ</arg>
</setting>
After creating a new placeholder batch for the Zelle payment, the new Zelle payment processing will use the generated batch id as a message selector and will monitor the new Zelle complete queue the message selector of the generated batch. When a message appears on the Zelle complete queue, that will signify to the Zelle application that the FTM payment process workflow has completed. The Zelle application will monitor the Zelle complete queue for the configured payment processing timeout value. If a message has not been received by the configured time, then the Zelle application will exit and return a failure to the user. To provide better controls, the Zelle payment processing timeout has been split into 2 different properties(Zelle Outbound Payment Processing Timeout, Zelle Inbound Payment Processing Timeout). These timeouts will be used when monitoring the Zelle complete queue.
For this process to work, the ITS scheduler must have a stanza that represents the “end” of the Zelle payment processing workflow. The new stanza must use the newly created ZelleCompletePresentmentStatesEventHandler. This new handler is based on the batch/presentment states of the Zelle payment.
The scheduler reference maintains the current workflow for both inbound and outbound payments where both Gateway and Risk must be executed for the Zelle payment to be completely processed. However, this can be adjusted (like other workflow processes) to meet the needs of the financial institution. The Scheduler reference contains the following stanza for the new event processor:
<EVENT>
<NAME>Zelle process complete</NAME>
<TYPE>PresentmentStateChange</TYPE>
<TYPE>PresentmentColumnChange</TYPE>
<TYPE>PresentmentGroupColumnChange</TYPE>
<EXEC>com.ibm.paydir.ima.txsvr.event.appbridge.ZelleCompletePresentmentStatesEventHandler</EXEC>
<PARAMETER name="msgType">zelleIngestComplete</PARAMETER>
<PARAMETER name="presStates1">LOADED,AUTH_REVIEWED</PARAMETER>
<PARAMETER name="paymentStandard">ZELLE</PARAMETER>
<PARAMETER name="pending">N</PARAMETER>
<PARAMETER name="group.pending">N</PARAMETER>
<PARAMETER name="presLevel">INB</PARAMETER>
<PARAMETER name="msgExpiryTime">30000</PARAMETER>
<PARAMETERREF>schedulerReferenceProperties</PARAMETERREF>
<PARAMETERREF>sendToZelleComplete</PARAMETERREF>
</EVENT>
<PARAMETERSET name="sendToZelleComplete">
<PARAMETER name="destinationID">Zelle Complete</PARAMETER>
<PARAMETER name="jmsSendQueue">FXH.ZELLE.COMPLETE.QUEUE</PARAMETER>
</PARAMETERSET>
The following sequence diagram shows the new Zelle payments processing flow.
Migration
Refer to the following documents for migration details:
DSUmigration_v3.2.3.pdf
DSUMigrationBR_v3.2.3.pdf
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
DSUmigration_v3.2.3.pdf
DSUMigrationBR_v3.2.3.pdf
Which can be downloaded from Fix Central at 3.2.3-FTM-DP-MP-Documents .
Related Information
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSPKQ5","label":"IBM Financial Transaction Manager"},"Component":"IBM Financial Transaction Manager for Digital Payments","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}],"Version":"3.2.2;3.2.2.0;3.2.2.1;3.2.3.0","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]
Was this topic helpful?
Document Information
Modified date:
10 March 2022
UID
ibm11073446