Fix Readme

Abstract

This document contains V3.0.6 Release Information for Financial Transaction Manager for ACH Services for Multiplatforms. Included are known issues and changes from previous releases.

Content

Financial Transaction Manager for ACH Services V3.0.6 Release Information

Contains release information for:

Financial Transaction Manager for ACH Services for Multiplatforms V3.0.6 (ACH)

Described are known issues and changes from previous releases. Start with the section for the release version you're currently working with and review each subsequent release for the changes.

Contents
Common Across Releases
V3.0.6, Fix Pack 11
... V3.0.6.11 iFix 1
... V3.0.6.11 iFix 2
V3.0.6, Fix Pack 10
... V3.0.6.10 iFix 1
... V3.0.6.10 iFix 2
V3.0.6, Fix Pack 9
V3.0.6, Fix Pack 8
V3.0.6, Fix Pack 7
... V3.0.6.7 iFix 1
... V3.0.6.7 iFix 2
... V3.0.6.7 iFix 3
V3.0.6, Fix Pack 6
V3.0.6, Fix Pack 5
... V3.0.6.5 iFix 1
... V3.0.6.5 iFix 2
... V3.0.6.5 iFix 3
... V3.0.6.5 iFix 4
V3.0.6, Fix Pack 4
V3.0.6, Fix Pack 3
... V3.0.6.3 iFix 1
V3.0.6, Fix Pack 2
... V3.0.6.2 iFix 1
3V.0.6, Fix Pack 1
... V3.0.6.1 iFix 1
... V3.0.6.1 iFix 2
... V3.0.6.1 iFix 3
... V3.0.6.1 iFix 4
... V3.0.6.1 iFix 5
... V3.0.6.1 iFix 6
... V3.0.6.1 iFix 7
... V3.0.6.1 iFix 8
... V3.0.6.1 iFix 9
... V3.0.6.1 iFix 10
V3.0.6, Fix Pack 0
... V3.0.6.0 iFix 1
... V3.0.6.0 iFix 2
... V3.0.6.0 iFix 3
... V3.0.6.0 iFix 4
... V3.0.6.0 iFix 5

Back to top	Common Across Releases

When upgrading a fix pack or interim fix (iFix), 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 iFixes.

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 / iFix 1 and upgrading to fix pack 1 / iFix 3, review the changes in fix pack 1 / iFix 2 and fix pack 1 / iFix 3.

Known Issues

Internet Explorer cannot open spreadsheets
Release 3.0.6 introduced a new security enhancement commonly known as Same-Origin Check. This feature allows the User Interface (UI) to optionally run same origin verification for requests from the browser.

There’s a known issue with Same-Origin Check enabled where Internet Explorer can’t open spreadsheets. Sample actions that will fail:

Inbound Transmission Hierarchy, Download Transmission
Processing Batches/ICLs, More > Actions > View as spreadsheet
Inbound Batches/ICLs, More > Actions > View as spreadsheet
Inbound Transactions, More > Actions > View as spreadsheet
Processing Batches/ICLs, select Rejects and Warnings link, Generate Report

As a work-around, customers should do one of the following:

Use Firefox.
Disable same origin verification using the user interface page at Administration > Components > Payment Feature Services > Properties. Set property XSRF Same Origin Check Enabled to false. Save. Restart FrameworkUI_EAR.

WebSphere Application Server 9.0.x update issue (Windows Only)

In WebSphere Application Server v9.0.x, there is a known problem updating components for an interim fix. This appears to only apply to Windows Operating System.

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 ifix components to update. These will appear in the <install> </install> section. You will also need to add these same components in the <uninstall> </uninstall> section.

Manual update workaround:

Before updating the Console WAR modules stop the FrameworkUI_EAR application, then proceed as normal. The Engine modules can be updated as normal.

Feature Changes

High Availability (HA)
"High Availability (HA) in a WebSphere Application Server clustered environment requires IBM MQ V8.0.0.5 or later."

IBM MQ
The IBM MQ Channel heartbeat interval setting will need to be adjusted if a shorter timeout is needed. This action can be accomplished in IBM MQ Explorer.

Fix list and new feature summary

For the list of fixes refer to Financial Transaction Manager for ACH Services V3.0.6 Fix list.

Note: The documents listed here will be used for the migration process described later in this document.

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

DSUmigration_V3.0.6.pdf
DSUMigrationBR_V3.0.6.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Database migration
For database migration instructions, refer to the migration instructions in {Install location}\shared\v306\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.0.6.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

General Instructions

Note: If this is a new installation (not an update to an existing product installation), see the installation information in the "FTM for ACH Installation" section of the Financial Transaction Manager for Multiplatforms documentation in IBM Knowledge Center.

Upgrade procedure

To upgrade an existing installation for a fix pack or interim fix (iFix), the following tasks need to be accomplished:

Pre-installation
Note: Installation Manager won’t update a file that has been modified after Installation Manager originally installed that file.

Ensure that the following components in the installation location aren’t running: RMI Service, Business Rules Distribution Manager, Business Rules Process Server, Gateway, Transaction Server.
Ensure that your installation doesn’t have any updated files from test fixes or modifications. Known directories or files that may have test fixes are:
1. Install location\shared\v306\pfs\BusinessRules\manager\lib\pdrmgrfx.jar.
2. Install location\shared\v306\pfs\BusinessRules\server\lib\pdrsvrfx.jar.
3. Install location\shared\v306\pfs\Gateway\lib\izxfix.jar.
4. Install location\shared\v306\pfs\ITS\lib\txfix.jar.

Installation

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

Deployment

Perform 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.
J2SE components: Install will overlay the J2SE applications so no special migration instructions are needed. Restarting those applications will update them with the fixes.
WebSphere Application Server (WAS) components: You may 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.
1. All WebSphere Servers must be restarted after all components have been 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 WAS profile deployment. If this is a new WAS profile and you have already installed the interim fix onto the prior installation, then you’ll need to perform two deployment passes. The first pass will be for the initial full product deployment and the second pass will be for those components affected by the interim fix.
3. If new tokens have been identified, then you’ll need to load your existing token file into the ADU Token File Wizard, update the new tokens with your configuration information, and save the token file.
Update your Transaction Server Scheduler.xml. Refer to the Transaction Server Scheduler XML section in this document for documentation. Note: this may not be required for your installation.
Refer to the release-specific section for changes that may affect your installation.
At this point, you can start your runtime components.
If you’re using the Data Setup Utility (DSU) worksheets capability for managing your data then update your worksheets. Refer to the Data Setup Utility section in this document for documentation.

Back to top	V3.0.6.11 iFix 2

Known issues

None.

Feature changes

None.

Migration

None.

Back to top	V3.0.6.11 iFix 1

Known issues

None.

Feature changes

None.

Migration

None.

Back to top	V3.0.6.11 Fix Pack

Note: This section contains any changes since the V3.0.6, Fix Pack 10 release.

Compatibility Matrix

Because the development of releases and interim fixes (iFixes) 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.0.6, Fix Pack 11.

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.0.6, Fix Pack 11, 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.0.6, Fix Pack 11, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 17
3.0.2.1	3.0.2.1 iFix 19
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.5.1	3.0.5.1 iFix 3
3.0.5.2	3.0.5.2
3.0.5.3	3.0.5.3 iFix 1
3.0.5.4	3.0.5.4 iFix 4
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 10
3.0.6.2	3.0.6.2 iFix 1
3.0.6.3	3.0.6.3 iFix 1
3.0.6.4	3.0.6.4
3.0.6.5	3.0.6.5 iFix 4
3.0.6.6	3.0.6.6
3.0.6.7	3.0.6.7 iFix 3
3.0.6.8	3.0.6.8
3.0.6.9	3.0.6.9
3.0.6.10	3.0.6.10 iFix 1

Known issues

None.

Feature changes

102207
Zelle: Small Business Payments to Supported Debit Cards

According to the below EWS mandate, payments and payment requests from a Small Business Customer cannot be made to tokens that are associated with debit cards.
image-20200218133123-1

If a payment is initiated from a Small Business token to a recipient token where the match recipient service call returns an active Debit Network Payment Profile, then the payment will be rejected with error code 172180: Small business payments cannot be sent to a debit card recipient.

If a payment request is initiated from a Small Business token to a recipient token where the match recipient service call returns an active Debit Network Payment Profile, then the payment request will be rejected with error code 181950: Small business payment requests cannot be sent to a debit card recipient (<token>).

102462
Zelle: Responder Name should continue to be a valid field in ZellePaymentRequest as it is today in CXCPaymentRequest

When the ZellePaymentRequest webservice was created, there was an effort to reduce the redundant/unneeded recipient/responder details that existed in the CXCPaymentRequest webservice and are stored at EWS. One of these fields was the responder name field.

This field was assumed to be the EWS name attached to the recipient's token. However, the participant's "nickname", if entered, takes precedence over the EWS name.

This field is being added to the ZellePaymentRequest webservice so that the ability to connect split payment requests with responders that are equated to the user's named recipient list.

99779 (APAR PH20315 )
Zelle: Restrict/Remove restriction SOAP message to EWS contains a hard coded reason description

The initial implementation for restricting/unrestricting EWS participants and tokens applied hard coded optional reason text fields when sent to EWS. The confirmation dialogs have been updated to include and optional reason text field that will allow the customer to input their own reason text for the applying the restriction or removing the restriction. The text entered here will be sent to EWS on the appropriate EWS webservice call.

Restrict participant confirmation
image-20200218134642-1

Unrestrict participant confirmation
image-20200218134733-2

Restrict token confirmation
image-20200218134900-3

Unrestrict token confirmation
image-20200218134941-4

Migration

None.

Back to top	V3.0.6.10 iFix 2

Known issues

None.

Feature changes

None.

Migration

None.

Back to top	V3.0.6.10 iFix 1

Known issues

None.

Feature changes

None.

Migration

None.

Back to top	V3.0.6, Fix Pack 10 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 9 release.

Compatibility Matrix

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.0.6, Fix Pack 10, 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.0.6, Fix Pack 10, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 16
3.0.2.1	3.0.2.1 iFix 18
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.5.1	3.0.5.1 iFix 3
3.0.5.2	3.0.5.2
3.0.5.3	3.0.5.3 iFix 1
3.0.5.4	3.0.5.4 iFix 1
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 10
3.0.6.2	3.0.6.2 iFix 1
3.0.6.3	3.0.6.3 iFix 1
3.0.6.4	3.0.6.4
3.0.6.5	3.0.6.5 iFix 4
3.0.6.6	3.0.6.6
3.0.6.7	3.0.6.7 iFix 2
3.0.6.8	3.0.6.8
3.0.6.9	3.0.6.9

Known issues

99779 (fixed in 3.0.6.11 - APAR PH20315 )
Zelle: RestrictTokenRequest SOAP message to EWS contains a hard coded reason description.

Feature changes

88018
Zelle Mandate - Ability to Restrict/Unrestrict token from FTM UI

EWS has mandated that FIs have the ability to restrict tokens and participants as well as have the ability to remove restrictions from tokens and participants.

FTM now provides this functionality on the partner grid screen and the Zelle tokens grid on the Zelle Participant Attributes screen.

According to the EWS specification:
- When a token OR participant is restricted, then the participant and ALL of the participant’s tokens are restricted.
- When a participant’s restriction is removed, the participant and ALL of the participant’s tokens will have the restriction removed.
- When a token’s restriction is removed, the token’s restriction is removed. When removing a token restriction, there is an indicator that determines whether the participant and all other participant tokens should have their restriction removed.

In FTM, when removing a restriction from a token, the restriction will ONLY be removed from that token. FTM will always set the “remove participant restriction” indicator to false when removing a restriction from a token. Removing a restriction from a participant will remove the restriction from the participant and all participant tokens (EWS processing).

When removing a restriction, FTM will update the participant and/or token status to be Inactive since EWS does not provide a token status change/profile status change for restriction removal.

The UI actions provided for restrict/unrestrict are always available for EWS participants/tokens regardless of the EWS status known to FTM. This means that a participant or token that is Restricted or Inactive continues to have the restrict/unrestrict UI actions available (assuming correct permissions are assigned). This is done to prevent any “out of sync” conditions that may occur between the FI and EWS so that the FI can still enforce restrictions/remove restrictions with EWS.

Restricting/unrestricting a Partner

Two new UI actions are available on the partner grid screen. One action to restrict the Zelle participant and one action to remove the restriction from the participant. As mentioned above, the action performed on the participant affects the participant and all its tokens. These new actions are only available to partners that have previously been registered as a Zelle participant.

image-20191030134231-1
Figure 1 Restrict participant

image-20191030134427-2
Figure 2 Unrestrict participant

Also, the EWS status for the participant are displayed on the details page of the partner (only for partners that have previously been registered as a Zelle participant).

image-20191030134530-3
Figure 3 Partner detail with EWS status

Restricting/unrestricting a Token

Two new actions will be available on the tokens grid in the Zelle Participant Attributes screen. One action to restrict the Zelle token and one action to remove the restriction from the token. As mentioned above, the action to restrict a token will restrict the selected token as well as the participant and all other participant tokens (as per EWS specification) and the action to unrestrict a token will ONLY remove the restriction from the selected token.

image-20191030134657-4
Figure 4 Restrict token

image-20191030134735-5
Figure 5 Unrestrict token

Restrict/unrestrict permissions

Two new permissions (Restrict Zelle participant/token and Unrestrict participant/token) have been added to control which users have the ability to restrict/unrestrict participants and tokens.

image-20191030134855-6

98419
Zelle Payment Cleanup Services Framework Task

The Zelle Payment Cleanup task searches the database for Zelle payments which timed out before input processing was completed. These payments are characterized with the value ‘generated’ in the Original Trace Number column of the inbound Transactions screen. The task will attempt to cancel these timed out payments through standard cancellation processing that did not occur when the payments initially timed out. The cancellation process will be tied closely to the configuration of the ITS scheduler which may include multiple components (such as Risk) in the payment cancellation workflow.

Currently, the task may only be run manually. It cannot currently be configured to run automatically on a scheduled basis.

The following steps are necessary to implement the Zelle Payment Cleanup task in Services Framework:

1.   Register the Zelle Payment Cleanup task
2.   Configure the Zelle Payment Cleanup task
3.   Run the Zelle Payment Cleanup task manually

Register the Zelle Payment Cleanup Task

To register the Zelle Payment Cleanup task, navigate to the registry page in the Services Framework user interface and select the Register Task link. The following table shows the fields that are needed to register the Zelle Payment Cleanup task.

Note that the task is contained in install_dir\ach\v306\RTP\tasks\Zelle\lib\Zelle_Tasks.jar.

This .jar file must be copied to the Services Framework application’s shared library directory and the application restarted to make the task available for registration.

Field	Description	Value	Example
Task classname	The name of the Zelle Payment Cleanup task Java class.	com.ibm.paydir.iyb.services.util.tasks.ZellePaymentCleanupTask
Task name	A descriptive name for the task	Customer specified	Zelle Payment Cleanup Task
Description	A detailed description about what the task does	Customer specified	Task for cancelling timed out Zelle payments

When the class name is entered, the user must click Verify to ensure the task is available in the Services Framework and see the configuration parameters needed for it to process. When all fields are entered for a task, click Register to register the task and make it available for configuration.

Configure the Zelle Payment Cleanup Task

To configure the Zelle Payment Cleanup task, navigate to the configuration page in the Services Framework user interface and select the New Task Configuration link. The following table shows the information needed to configure the Zelle Payment Cleanup task.

Field	Description	Example
Task	Contains the registered tasks in the system. Select the name of the Zelle Payment Cleanup task that was entered during registration.	Zelle Payment Cleanup Task
Configuration	A descriptive name for the configuration. This field is required and can contain up to 60 characters.	Zelle Payment Cleanup Task
Description	A detailed description explaining what the task does. This field is optional. If entered, it must be 512 characters or less.	Task for cancelling timed out Zelle payments
Activate task	Identifies if the configuration is active. When it is active, the task is available to cancel timed out payments.	Yes, No
Process end of day	This flag is not applicable for the Zelle Payment Cleanup task. It is recommended to set this value to no.	No
Process cleanup	This flag is not applicable for the Zelle Payment Cleanup task. It is recommended to set this value to no.	No
Delete on complete	Identifies if the activity for this task is deleted when it is complete. If set to yes, the activity for this task is deleted when it successfully completes and is not deleted when it has errors or warnings. If set to no, the activity for this task is not deleted when it completes.	Yes, No
Allow monitor	This flag is not applicable for the Zelle Payment Cleanup task. It is recommended to set this value to no.	No
Endpoint	The Endpoint this task should use when querying the database, For performance this value should be set. If not supplied, the task will scan the entire partition for the current business day when attempting to retrieve transactions to cancel. A new configuration of the task can be created for each desired endpoint.	ZELLEIN
Business Day Category	The Business Day Category the task should use when determining the business day to cancel payments. Note that this parameter is not validated. If an invalid category is supplied, the task will not retrieve business days, and will not cancel payments.	ZELLE

Run the Zelle Payment Cleanup Task

To execute the Zelle Payment Cleanup task, navigate to the Task Operation page in the Services Framework user interface and click the Run Configuration icon beside the task. The following table shows the information needed to configure the Zelle Payment Cleanup task runtime parameters.

Field	Description	Example
Payment ID	Payment ID of the transaction to be cancelled. If no value is provided, the task will look for any payments to be cleaned up for the configured Business Date.	121
Business Date	Business Date to attempt to clean up. This should be in YYMMDD format. If no value is supplied, the current date will be used.	191021

92168
Zelle Mandate - RDFI to Originate Dispute Settlement Forward Payment

If an RDFI receives a ZELLE payment (ZELLE_Recv) and a corresponding NACHA settlement transaction for that payment, then the RDFI needs a way to possibly dispute that transaction.

According to the EWS mandate: “Receiving Organization: Returns the payment to the Sending FI using the Disputes Settlement RTN and Account number stored for the Sending Organization in Shared Directory.”

It was assumed that the current ACH Returns process would be used for disputes. However, the ACH returns process does not meet the mandate of sending disputed funds to a specific dispute settlement RTN/account. Also, the ACH returns process, assumes the entire amount of the transaction should be returned so it does not support smaller disputed amounts.

To allow processing for this dispute account mandate, FTM has been updated to allow Zelle RDFIs to originate dispute forward payments from the transactions grid user interface. The new dispute action will allow for an alternative amount (less than the original amount) to be sent to the ODFIs dispute settlement or realtime/standard settlement account.

The new “Zelle Dispute” action will be available on the Transactions grid screen.

image-20191030122147-1

The action will be available to the logged in user if the user has the correct permission. The action will be allowed if the following are true:

A single transaction is selected.
The transaction is a NACHA settlement item for a ZELLE_Recv transaction.
The selected transaction has not been previously returned or disputed.
The corresponding ODFI EWS organization has a configured dispute settlement account (initial lookup) OR a configured real time/standard settlement account based on the type of ZELLE_Recv transaction (real time/standard).

If the selected transaction(s) do not meet the above criteria, then an error message will be displayed, and the action will not be allowed.

If the selected transaction meets the required criteria, the following dialog will be displayed:

image-20191030122517-2

The dialog will display information for the transaction being disputed. The user can provide an (optional) alternative amount for the disputed transaction. The alternative amount will be a numeric field that will represent the amount to be credited to the ODFI. The alternative amount will be a numeric field that will be interpreted as dollars and cents.

For example:
222 will be treated as $222.00
12.45 will be treated as $12.45

The entered amount must be a number greater than zero and cannot be greater than the amount of the original transaction.

If this field does not meet the valid criteria, then the field will be marked in error and the user will not be allowed to continue.

image-20191030122735-3

When the “Dispute” button is selected, the user will be shown a confirmation dialog. If an alternative amount was not entered, the user will be shown the following confirmation dialog that denotes that the dispute transaction will be created using the full original amount.

image-20191030122832-4

If a valid alternative amount is entered, the user will be shown the following confirmation dialog that denotes that the dispute transaction will be created with the entered alternative amount.

image-20191030122925-5

Once the user confirms the action, the dispute process will be started, and a success banner will be displayed on the UI.

image-20191030123001-6

When the Zelle Dispute action is taken, the following will occur for the new INTERNAL transaction:

The originator’s bank code (ODFI) will be set as the destination bank .
The dispute/settlement account number (ODFI Zelle organization) will be set as the destination account.
It will be a Credit transaction.
If an alternative amount was entered, that amount will be set as the new transaction’s amount.
The new transaction’s alternative id will be set to the same value as the original transaction (Zelle payment id).
The new transaction will be related to the original settlement transaction with a “DISPUTE_OF” relationship.
The original transaction’s status will be set to “Disputed” (new transaction status).
The dispute action will be audited in the audit log.

The following shows an example transactions UI grid that contains the ZELLE_Recv transaction, the CCD settlement transaction and the INTERNAL dispute transaction after the Zelle dispute action has been taken.

image-20191030123153-7

The alternative ids have all been set to the same Zelle payment id value. The CCD settlement transaction status has been set to Disputed. The INTERNAL dispute transaction is a Transit item with an amount ($25.50) less than the original transaction amount ($111.11).

With the DISPUTE_OF relationship, all 3 transactions (ZELLE_Recv, CCD, INTERNAL) will be linked. The Related Transactions tab in the transaction details for the settlement transaction shows that it is related to both the ZELLE_Recv (SETTLEMENT_OF) and the INTERNAL dispute transaction (DISPUTE_OF).

image-20191030123253-8

The ITS scheduler has been updated to allow internally generated batches (both forward and return batches) to be processed for possible funds reversals. The application will now include processing of the DISPUTE_OF relationship to determine if the internally generated transaction is a disputed ZELLE_Recv transaction. If found to be a dispute, the funds will be reversed and customer notifications will be sent to reflect the updates.

CXCPayment/Funds Transfer UX/Send Notifications UX

The CXCPayment object contains a new “disputeAmount” field. This field will only be set when a dispute is in progress. When set, the Funds Transfer UX and Send Notifications UX can use the disputeAmount field to update processes to handle the possibility that the dispute amount is less than the original amount. The sample user exits have been updated to provide examples of how to use this new field.

A new sample ZELDISPUTE endpoint and Zelle Dispute Ach transmission definition (defined in the Sample DSU spreadsheets) have been created to clearly denote that the generated outbound NACHA files are Zelle Dispute files. The ZELDISPUTE will be assigned to the internally generated dispute items (as a sample).

92169
Zelle Mandate - ODFI to Receive Dispute Settlement Forward Payment

EWS has mandated that RDFI's should dispute transactions to the EWS organization's specified dispute settlement account.

With this mandate, the ODFI processing of incoming NACHA transactions has been updated to process possible dispute transactions that are received as incoming credits targeted for the ODFI's specified dispute account.

The provided Reconciliation Task (com.ibm.paydir.iyb.services.util.tasks.ReconcileTask) has been updated to determine if the received transaction is associated to a ZELLE_Orig transaction (by Zelle payment id) and the transaction is targeted for the FI's EWS specified dispute account. If that is the case, the inbound NACHA transaction will be related to the original ZELLE_Orig transaction as a "DISPUTE_OF" transaction relationship. This relationship will be seen on the transaction details/Related transactions user interface tab.

image-20191030132246-1

The Reconciliation Task will now set the ZELLE_RECONCILED state on the ZELLE_Orig transaction as well as the ZELLE_RECONCILIATION state on the containing batch for the transactions that are deemed to be disputes.

The setting of the ZELLE_RECONCILIATION state on the ZELLE_Orig batch will cause the Zelle Reconciliation Funds Transfer Task to be executed (assuming usage of the reference ITS scheduler). The task will now include processing of the DISPUTE_OF relationship to determine that the ZELLE_Orig transaction has been disputed and all/some of the funds should be reversed back to the customer’s account. Notification to the customer will also be available via the notifications user exit.

CXCPayment/Funds Transfer UX/Send Notifications UX

Migration

None.

Back to top	V3.0.6, Fix Pack 9 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 8 release.

Compatibility Matrix

Because the development of releases and interim fixes (iFix) for maintenance is 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.0.6, Fix Pack 9.

In the 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.0.6, Fix Pack 9, 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.0.6, Fix Pack 9, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 16
3.0.2.1	3.0.2.1 iFix 18
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.5.1	3.0.5.1 iFix 2
3.0.5.2	3.0.5.2
3.0.5.3	3.0.5.3 iFix 1
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 10
3.0.6.2	3.0.6.2 iFix 1
3.0.6.3	3.0.6.3 iFix 1
3.0.6.4	3.0.6.4
3.0.6.5	3.0.6.5 iFix 4
3.0.6.6	3.0.6.6
3.0.6.7	3.0.6.7 iFix 1
3.0.6.8	3.0.6.8

Known issues

None.

Feature changes

97465
Zelle: Extend 18 month Token Verification to include Customer Verification

The initial EWS token usage tracking functionality tracked only token usage (payments sent and payments received for a token). This requirement has now been extended to include tracking usage of EWS participants. This includes tracking any payments originated by a participant's account information (no token usage).

Updates have been made to FTM so that EWS participant usage will now be tracked along with individual token usage. The participant usage will be updated whenever a payment is sent from a participant's account or from any of the participant's tokens. The participant usage will also be updated whenever a payment is received for any of their tokens.

A new VERIFIED column has been added to the token usage table. This will allow customer's the ability to manually set the last time that the participant or token was verified to still be in use.

The sample token usage report (Zelle Token Usage Data) has been modified to give 4 different views of the data:

Customer (non-token) activity based on latest timestamp of the last verified and last used columns
Token activity based on latest timestamp of the last verified and last used columns
Customer (non-token) activity based on the latest last used columns
Token activity based on the latest last used columns

Migration

The following document contains the instructions that are needed to migrate from V3.0.6, Fix Pack 8 to V3.0.6, Fix Pack 9:

FTM_ACHServices_V3.0.6.9_Migration.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Back to top	V3.0.6, Fix Pack 8 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 7 release.

Compatibility Matrix

In the 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.0.6, Fix Pack 8, 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.0.6, Fix Pack 8, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 16
3.0.2.1	3.0.2.1 iFix 18
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.5.1	3.0.5.1 iFix 2
3.0.5.2	3.0.5.2
3.0.5.3	3.0.5.3 iFix 1
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 10
3.0.6.2	3.0.6.2 iFix 1
3.0.6.3	3.0.6.3 iFix 1
3.0.6.4	3.0.6.4
3.0.6.5	3.0.6.5 iFix 4
3.0.6.6	3.0.6.6
3.0.6.7	3.0.6.7

Known issues

None.

Feature changes

95267
Use "Token Type" to determine Zelle Product Code

In 3.0.6.6, EWS Small Business support was added to FTM. The initial implementation relied on Business Rules to determine deposit product code assignment (which controls Risk limit monitors as well as potential additional billing configuration) for the Zelle transactions. The initial Sample Business Rules implementation provided product code assignment based on the Customer Type for the partner. This allowed FIs to configure a partner as a Small Business or a Person. This implementation did not provide enough flexibility for those customers that may have accounts/tokens for both small businesses and personal use.

CXCPayment
In V3.0.6, Fix Pack 6, a Transaction Type field was added to the CXCPayment. This field was defined as:

The possible values for originated payments were:
- P2P (Person to person)
- B2C (Business to consumer)
- C2B (Consumer to business)
- B2B (Business to business)
- P2U (Personal to unknown)
- B2U (Business to unknown)

For received payments, the possible Transaction Type values were:
- PERSONAL_RECEIVED
- BUSINESS_RECEIVED

The Transaction Type field is being changed to Transaction Category and the values are being changed. Transaction Type is generally associated with credit/debit. So, the name change is to delineate the Transaction Category field from that connotation. The values for the new field are:

The possible values for originated payments are:
- P2P (Person to person)
- B2C (Business to consumer)
- C2B (Consumer to business)
- B2B (Business to business)
- C2U (Consumer to unknown)
- B2U (Business to unknown)

For received payments, the sender’s profile is never known. The possible Transaction Category values are:
- U2C (Unknown to Consumer)
- U2B (Unknown to Business)

NOTE:

The change from Transaction Type to Transaction Category means that the CXCPayment object has changed. The readCXCPayment webservice will now return a TransactionCategory field (with the above values) instead of TransactionType.

Also, any user exits will need to be updated if the Transaction Type was being used. The user exit will need to be updated to use the new Transaction Category field.

com.ibm.fxh.zel.database.objects.TransactionType -> com.ibm.fxh.pmtacc.database.objects.TransactionCategory

*******

Zelle Core Property
The “Small Business Origination Product Code” property is being updated to be “Small Business Product Codes”. This property will now be treated as a comma-separated list of deposit product codes. The product codes entered here should be all the small business product codes (origination and receipt) that a Zelle participant will be subscribed when the participant is registered.

SAMPLE configuration and SAMPLE Business Rules
There have been updates and additions made to the SAMPLE configuration. In the initial implementation for small business, a ‘ZSMB’ product code was added for Zelle Small Business Origination. This product code has been changed to be ‘ZSBO’ and a companion Zelle Small Business Receipt (‘ZSBR’) product code had been added.

Business Rules has been updated so that deposit product codes can be assigned by using the new Transaction Category value. This will allow product codes to be assigned on a transaction by transaction basis. The ability to assign product codes based on Customer Type remains as well. So, the FI can control how the product codes are assigned.

The SAMPLE Business Rules configuration has been updated to allow for using the transaction category as a means of small business product code assignment.

Migration

The following document contains the instructions that are needed to migrate from V3.0.6, Fix Pack 7 to V3.0.6, Fix Pack 8:

FTM_ACHServices_V3.0.6.8_Migration.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Back to top	V3.0.6.7 iFix 3

Known issues

None.

Feature changes

None.

Migration

None.

Back to top	V3.0.6.7 iFix 2

Known issues

None.

Feature changes

None.

Migration

None.

Back to top	V3.0.6.7 iFix 1

Known issues

None.

Feature changes

None.

Migration

None.

Back to top	V3.0.6, Fix Pack 7 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 6 release.

Compatibility Matrix

In the 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.0.6, Fix Pack 7, 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.0.6, Fix Pack 7, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 15
3.0.2.1	3.0.2.1 iFix 18
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.5.1	3.0.5.1 iFix 2
3.0.5.2	3.0.5.2
3.0.5.3	3.0.5.3
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 10
3.0.6.2	3.0.6.2 iFix 1
3.0.6.3	3.0.6.3 iFix 1
3.0.6.4	3.0.6.4
3.0.6.5	3.0.6.5 iFix 4
3.0.6.6	3.0.6.6

The minimum EWS version required for FTM V3.0.6, Fix Pack 7 is EWS V3.10.
The following is a list of supported EWS notifications and supported EWS SOAP requests.

Notification	Version
OnTokenStatusChangeNotification	3.10
OnPaymentProfileStatusChangeNotification	2.0
OnNewPaymentNotification	3.9
OnPaymentStatusChangeNotification	3.9
OnNewPaymentRequestNotification	3.0
OnPaymentRequestChangeNotification	2.4
OnCustomerChangeNotification	2.4
OnOrganizationsChangeNotification	3.9

Request	Version
AddPaymentRequest	3.10
ChangePaymentRequestRequest	2.4
ChangePaymentStatusRequest	3.9
DeactivateCustomerRequest	2.4
DeletePaymentProfileRequest	--
GetCustomerEventDetailsRequest	3.0
GetOrganizationsRequest	3.9
GetPaymentRequest	3.9
GetPaymentRequestDetailsRequest	3.0
GetPendingActivityForTokenRequest	3.2
GetTokenHistoryRequest	3.10
MatchRecipientRequest	3.10
RegisterTokenRequest	3.10
RequestPaymentsRequest	3.10
UnregisterTokenRequest	3.10
UpdateBusinessPaymentProfileRequest	3.8
UpdatePersonalPaymentProfileRequest	3.0

Known issues

None.

Feature changes

77674
If an EWS payment is received from a debit card OR sent to a debit card, there is a need to store the debit card PAN (last four digits of the card).

Inbound payment
If an OnNewPayment notification is received from EWS, the sender’s debit card details will be included as part of that notification. If those debit card details exist, then FTM will retrieve the debit card PAN data (detailed as last-four-digits in the notification) and store it as part of the cxcPayment.

Outbound payment
When a new Zelle payment is originated, FTM will attempt to match the recipient with EWS. If the match recipient response denotes that the receiver token is attached to a debit card (debit-network-profile-details in the response), then FTM will retrieve the debit card PAN (if available) and store it as part of the cxcPayment.

The debit card PAN data will be available to all user exits that have access to the cxcPayment object. The value can be retrieved from the cxcPayment object via the getDebitCardLastFourDigits() method.

Note: For incoming payments, the PAN information will be for the sender of the payment. For outgoing payments, the PAN information will be for the receiver of the payment.

The debit card PAN information (when available) will be displayed on the Zelle tab of the transaction details screen:

image-20190606121150-1

The PAN information may also be available on the Debit Transaction details received from EWS. That information will be displayed on the Debit Card Information tab of the transaction details screen:

image-20190606121307-2

93392
EWS is requiring participants to confirm that their customer tokens are still valid and associated with that customer when a payment has not been sent or received within the past eighteen (18) months.

In order to expedite this information gathering, FTM will now track the last payment sent and received from token/payment profile in a new TOKEN_USAGE database table. The database migration to 3.0.6.7 will update the TOKEN_USAGE with the existing token usage data.

A sample token usage report (Zelle Token Usage Data) has been created and is available with 3.0.6.7.

Note:
An optional initialization script (populate_token_usage.sql) is included with 3.0.6.7. This script will populate the TOKEN_USAGE table with the current token usage data that exists in the system. The initialization script can be found in the 3.0.6.7 installation at: "\db2\<OS>\util" where <OS> is equal to win, unix, or zos.

93393
EWS is introducing a new record layout (version 2) for their Debit Network Transaction Detail file. The updated format is detailed in EWS’s “Supported Debit Network Transaction Detail Record Specification v2” specification.

The specification details the addition of the following fields:
•   version
•   payment.productType
•   sender.issuingOrgId
•   recipient.issuingOrgId
•   debitNetwork.caid
•   debitNetwork.visaRetrievalReference
•   sender.senderName

FTM’s Debit Card File reader has been updated to handle ingesting version 2 Debit Network Transaction Detail files. FTM will now be able to ingest both version 1 and version 2 of the EWS file.

The Debit Card fields received in these files will now be displayed on a new “Debit Card Information” tab on the transaction detail screen:

image-20190606121923-3

The screen will display the fields in name-value pairs where the name is the name defined in the specification.

The new tab will be displayed for both version 1 and version 2 debit card items. The new version 2 fields will ONLY display on transactions that were ingested as part of a version 2 file. Items received in a version 1 file will NOT have placeholders for these new fields.

94221
Made returned error code changes when trying to create a token.

The following error code will be returned if the token AND the payment profile are active
150500: The token <name> is already active in CXC.

If the payment profile is active, but the token is inactive, then the following error code will be returned:
150510: The token <name> was found in the system, but it is not active. Please use the update token service to reactivate.

94419
A new deactivateOnAnyAmount field has been added to the createCXCPaymentRequest webservice. The field will allow control over whether the payment request should be deactivated whenever a payment is received for the payment request (regardless of amount). If this field is set to FALSE, then the payment request will remain active until the request is paid in full or is updated by the user.

This new field will be defaulted to TRUE if not supplied on the webservice.

Note: To maintain consistency, the default value of the same deactivateOnAnyAmount field on the createZellePaymentRequest has been changed from FALSE to TRUE. If the field is not provided on the createZellePaymentRequest webservice, then it will be defaulted to TRUE and the payment request(s) will be deactivated if/when a payment is received for that request (regardless of amount).

95159
To be more inline with the EWS specification for payment request deactivation reasons, partial payment (underpayment) payment requests will be assigned a deactivation reason of PAID. Previously, underpayment payment requests were assigned a deactivation reason of COMPLETE.

92166
A new optional "isRecurring" flag (Y/N) will be included on the create cxcpayment webservice. If set to Y, the created payment will be marked as a recurring/scheduled payment.

The "isRecurring" flag will be included in the response from the read cxcpayment webservice.

The "isRecurring" flag that was included in the read cxcparticipantview webservice will be changed from a boolean value (true/false) to a String representation (Y/N).

Migration

The following document contains the instructions that are needed to migrate from V3.0.6, Fix Pack 6 to V3.0.6, Fix Pack 7:

FTM_ACHServices_V3.0.6.7_Migration.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Back to top	V3.0.6, Fix Pack 6 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 5 release.

Compatibility Matrix

In the 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.0.6, Fix Pack 6, 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.0.6, Fix Pack 6, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 15
3.0.2.1	3.0.2.1 iFix 15
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.5.1	3.0.5.1
3.0.5.2	3.0.5.2
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 10
3.0.6.2	3.0.6.2 iFix 1
3.0.6.3	3.0.6.3 iFix 1
3.0.6.4	3.0.6.4
3.0.6.5	3.0.6.5

The minimum EWS version required for FTM V3.0.6, Fix Pack 6 is EWS V3.10.
The following is a list of supported EWS notifications and supported EWS SOAP requests.

Notification	Version
OnTokenStatusChangeNotification	3.10
OnPaymentProfileStatusChangeNotification	2.0
OnNewPaymentNotification	3.9
OnPaymentStatusChangeNotification	3.9
OnNewPaymentRequestNotification	3.0
OnPaymentRequestChangeNotification	2.4
OnCustomerChangeNotification	2.4
OnOrganizationsChangeNotification	3.9

Request	Version
AddPaymentRequest	3.10
ChangePaymentRequestRequest	2.4
ChangePaymentStatusRequest	3.9
DeactivateCustomerRequest	2.4
DeletePaymentProfileRequest	--
GetCustomerEventDetailsRequest	3.0
GetOrganizationsRequest	3.9
GetPaymentRequest	3.9
GetPaymentRequestDetailsRequest	3.0
GetPendingActivityForTokenRequest	3.2
GetTokenHistoryRequest	3.10
MatchRecipientRequest	3.10
RegisterTokenRequest	3.10
RequestPaymentsRequest	3.10
UnregisterTokenRequest	3.10
UpdateBusinessPaymentProfileRequest	3.8
UpdatePersonalPaymentProfileRequest	3.0

Known issues

None.

Feature changes

90531
Support OnOrganizationsChangeNotification

FTM has supported the EWS call GetOrganizations via a services framework task. This task calls EWS and returns ALL of the organizations at EWS. This could become cumbersome as the list of organizations grow.

EWS also provides an OnOrganizationsChangeNotification that provides a list of defined organizations (at EWS). This notification can be configured by the FI to contain ALL of the defined organizations OR only the organizations that have changed.

FTM will now support the OnOrganizationsChangeNotification which will allow the organization updates to be pushed from EWS. The Services Framework task and the handling of the OnOrganizationsChangeNotification will use common logic to update the organizations. The difference will be the number of organizations in the list that is returned/received.

86576
Small & Medium Business Attribute Support

EWS now supports small business payment profiles as well as personal payment profiles.

In support of small business profiles, FTM has made changes to allow for tokens to be registered and flagged as small business payment profiles.

It is suggested that if a business participant needs to be defined in the UI, then the customerType on the CXCParticipant should be set to the corresponding configured Zelle small business customer type.

A new Small Business Product origination code can be configured in the Zelle core properties that will allow for different Risk limits to be assigned. A sample 'ZSMB' is included and the sample Business Rules spreadsheet will include an example of assigning this new product code by customer type (*see customerType note above).

New Account Types
FTM will allow the settlement of Small Business funds into a separate settlement account by supplying two new account types (Zelle Small Business Standard Payments, Zelle Small Business Real-time Payments).

These account types can be configured for the customers EWS organization that is listed as an FTM partner.

The GetOrganizations call (or notification) will supply several account types, Standard, Real-Time, Visa, Mastercard, Disputes. The new small business account types will need to be configured outside of the handling of the EWS organizations. Once the small business accounts are configured, the organization updates from EWS should not affect that configuration.

The new small business accounts can be used internally through the FundsTransfer User Exit. The Sample User Exit will be updated to make use of the Small Business accounts as an example.

Web service updates

In support of the Business Profile functionality the following Web Services have been changed/upgraded:

CXCToken
----------------
Several new attributes have been added to the CXCToken Web Services to support business profiles.
-       profileType
-       businessName
-       addressLine1
-       addressLine2
-       city
-       state
-       zipCode
-       countryCode
-       contactEmail
-       contactPhone

Profile type, if not provided will default to PERSONAL ("P").

If a profile is being registered as a Business Profile, business name is required.

When creating a token, the first call to EWS's registerToken service will have the Business Name in the firstName field that is sent to EWS. FTM will then call the updateBusinessPaymentProfile EWS service to convert the newly registered personal token to be a business profile. If the updateBusinessPaymentProfile call fails for any reason, then the personal token that was registered with EWS is unregistered. This will allow for the token to be registered again whenever the error condition is cleared.

If any part of the business address for a profile is provided, all required fields must be present, or a validation error will occur and return Error Code 151900.

A personal token can be later converted to a business profile by using the updateCXCToken with the profileType set to BUSINESS ("B").

CXCMultiToken
------------------
The set of tokens contained within the multi token object will reflect the added small business data of the CXCToken.

CXCRecipients
----------------
No Change in Web Service Behavior.

The Recipient screen in the FTM UI has had the First Name column renamed to First Name/Business Name. When matching the recipient, the firstName field will function as the given name for personal profiles and business name for business profiles.

CXCPayments
----------------
CXCPayments have two new fields displayed on the Read call
- OriginatorType
- TransactionType

On a Create call, OriginatorType (PERSONAL, SMALL_BUSINESS) is an optional input parameter. This can be included when a payment is originated by an account number (instead of a token) which will allow the generated transaction to be tracked just as a payment originated from a token.

If the originator token is provided, and the OriginatorType is not, the originator type will be derived from the profile type for the provided token. If neither are provided, the originator type defaults to PERSONAL.

The transaction type is determined by FTM.

The possible values for originated payments are:
- P2P (Person to person)
- B2C (Business to consumer)
- C2B (Consumer to business)
- B2B (Business to business)
- P2U (Personal to unknown)
- B2U (Business to unknown)

For payments that are sent to unknown recipients, the transaction type defaults to either P2U or B2U. When the unknown token is registered, the transaction type is updated to reflect the profile type of the new token.

For received payments, the possible transaction type values are:
- PERSONAL_RECEIVED
- BUSINESS_RECEIVED

On received payments, the originator type defaults to PERSONAL and the transaction type is either PERSONAL_RECEIVED or BUSINESS_RECEIVED, which will denote that the transaction is being sent to a business or personal token.

90698
Java JRE

Fix Pack V3.0.6, Fix Pack 6 will ship with Java 8 (JRE).

Migration

The following document contains the instructions that are needed to migrate from V3.0.6, Fix Pack 5 to V3.0.6, Fix Pack 6:

FTM_ACHServices_V3.0.6.6_Migration.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Back to top	V3.0.6.5 iFix 4

Feature changes

None.

Back to top	V3.0.6.5 iFix 3

Feature changes

None.

Back to top	V3.0.6.5 iFix 2

Feature changes

None.

Back to top	V3.0.6.5 iFix 1

Feature changes

None.

Back to top	V3.0.6, Fix Pack 5 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 4 release.

Compatibility Matrix

In the 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.0.6, Fix Pack 5, 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.0.6, Fix Pack 5, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 14
3.0.2.1	3.0.2.1 iFix 15
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.5.1	3.0.5.1
3.0.5.2	3.0.5.2
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 8
3.0.6.2	3.0.6.2 iFix 1
3.0.6.3	3.0.6.3 iFix 1
3.0.6.4	3.0.6.4

Known issues

None.

Feature changes

84722
Network-level Token/Consumer restriction

Overview

Enhancements have been made to support Early Warning Services (EWS) V3.10 network level token/consumer restrictions. FTM will process and honor any restrictions that have been placed on tokens/consumers.

A restricted token will not be allowed to be registered.
Users will not be allowed to originate payments and payment requests from a restricted token, a restricted consumer ID, or both.
Payments and payment requests will not be allowed to be sent to restricted tokens/consumers.
When an EWS token status change of restricted is received, that token will display with a "restricted" status in the user interface and web services.

Updated Early Warning Services (EWS) notifications

The following EWS Notification updates have been made:

From OnNewPaymentNotification38 to OnNewPaymentNotification39
From OnTokenStatusChangeNotification to OnTokenStatusChangeNotification310

FTM will now support the notifications shown above.

Updated Early Warning Services (EWS) requests

The following EWS request updates have been made:

From AddPaymentRequest38 to AddPaymentRequest310
From GetTokenHistoryRequest30 to GetTokenHistoryRequest310
From MatchRecipientRequest38 to MatchRecipientRequest310
From RegisterTokenRequest38 to RegisterTokenRequest310
From RequestPaymentsRequest38 to RequestPaymentsRequest310
From UnregisterTokenRequest36 to UnregisterTokenRequest310

Change Details

Following is a more detailed synopsis of the changes:

CXCToken

Cannot register a token to a restricted consumer.
Cannot register a restricted token
OnTokenStatusChange can update the token status to restricted. FTM will reflect this change and can be viewed on the user interface and seen in the read web services.
If the FTM token status is restricted, then FTM will not allow payments or payment requests to be made from that token. Any web service that incurs this scenario will have an error returned of the form: "122800: Token (<token>) is restricted."
EWS will not allow unregistering a restricted token. A failure reason code of "cannot-change-from-restricted-to-inactive" will be returned.

CXCRecipients

Reflect the new Restricted status on CXCRecipient entities. This status should be viewable in the UI and on any Read recipient web services.
The user will be able to add restricted recipients. The restricted status will be reflected, but the user will not be able to make payments or payment requests to that recipient. The CXCRecipient list is used solely as an ease of use address book for the user. Allowing restricted tokens to be added as recipients will allow those entries to be maintained in the address book in case the restriction is lifted.
OnTokenStatusChange notification received will update any related recipient entity.

Ex.

FTM receives a notification that test@test.com is restricted.

The CXCToken for test@test.com will be updated to restricted for the owning partner (Partner A).

Any other partners (Partner B) that have test@test.com in their CXCRecipient list will have those entries updated to restricted as well.

Partner A's token screen will reflect that the token is restricted.

Partner B's recipient screen will reflect that the test@test.com recipient is restricted.

CXCPayments

If the originator token has a restricted status in FTM, then the web service response will be: "122800: Token (<token>) is restricted." No transaction will be created in FTM.
If the originator token is active in FTM, but restricted in EWS, then the AddPaymentResponse will fail with a failure reason code of "sender-is-restricted". This reason is assumed to be what is returned because the originating token is not sent to EWS (just the customer ID). An FTM transaction will be created, but it will be cancelled.
If the originator token is active in FTM OR the payment request contains account information (not tied to a token), but the consumer is restricted in EWS, then the AddPaymentResponse will fail with a failure reason code of "sender-is-restricted". An FTM transaction will be created, but it will be cancelled.
If the receiving token is restricted at Early Warning Services, the MatchRecipientResponse returns that the token is restricted. When FTM receives this response, the create payment web service response is: "122810: Early Warning returned that <token> is restricted." No transaction will be created in FTM.
If the receiving token passes the MatchRecipient call but is restricted when the AddPaymentRequest is called, the AddPaymentResponse returns a failure with a failure reason code of: "token-is-restricted" An FTM transaction will be created, but it will be cancelled.
All of the above failures will be handled the same as existing failures.

PaymentRequests

If the requester token has a restricted status in FTM, the web service response is: "122800: Token (<token>) is restricted." No FTM transaction will be created.
If the requester token is active in FTM but restricted in EWS, the RequestPaymentsResponse fails with a failure reason code of "requester-is-restricted". An FTM transaction will be created, but it will be cancelled.
If the requester token is active in FTM but the customer is restricted in EWS, the RequestPaymentsResponse will fail with a failure reason code of "requester-is-restricted". An FTM transaction will be created, but it will be cancelled.
If one of the responder tokens is restricted at EWS, the MatchRecipientResponse returns that the token is restricted. When FTM receives this response, the create payment request (both CXCPaymentRequest and ZellePaymentRequest) web service response is: "122810: Early Warning returned that <token> is restricted." No transactions will be created in FTM.
On the ZellePaymentRequest web service, there can be a list of responders. The above error (122810) will be thrown when the FIRST restricted token is found. If there are additional tokens in the list, the EWS Match Recipient call will not be made for those tokens.
If the responder tokens all pass the MatchRecipient call, but any are restricted when RequestPayments is called, the RequestPaymentsResponse returns a success. However, there is a list of paymentrequestresults for each request in the list. Each of these can have nodes that denote error conditions. With restricted tokens/customers, there is now potential that the following may be set in each: TokenIsRestricted, ResponderIsRestricted. If these nodes (or any of the other error nodes) exist, the payment request associated with the error will be cancelled in FTM. The resulting deactivation memo and reason will be returned in the ZellePaymentRequest response. The CXCPaymentRequestResponse succeeds and the caller needs to perform the read CXCPaymentRequest to see the deactivation results.
All of the above failures will be handled the same as existing failures.

Scheduled Zelle payments

A new Zelle recurring model is only allowed IF the originator's token status (in FTM) is active.
If an OnTokenStatusChange notification is received that a token is restricted, any existing scheduled payments will remain active. Successive payment initiations will fail (as noted above).

Notes:

FTM does not provide the ability, by the user interface or a web service, to restrict or unrestrict a user or token. The functionality that has been added for restrictions is for processing the status updates from EWS and corresponding data changes. Early Warning Services has agreed to allow financial institutions (FIs) to use their client tools to perform restrict/un-restrict actions.

Migration

The following document contains the instructions that are needed to migrate from V3.0.6, Fix Pack 4 to V3.0.6, Fix Pack 5:

FTM_ACHServices_V3.0.6.5_Migration.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Back to top	V3.0.6, Fix Pack 4 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 3 release.

Compatibility Matrix

In the 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.0.6, Fix Pack 4, 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.0.6, Fix Pack 4, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 14
3.0.2.1	3.0.2.1 iFix 15
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.5.1	3.0.5.1
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 7
3.0.6.2	3.0.6.2 iFix 1
3.0.6.3	3.0.6.3 iFix 1

Known issues

None.

Feature changes

84776
Limit Management

Partner Details page
There is a new hyperlink added on the Partner Details user interface page with the title "View Exposure Limit Monitoring". This new link is displayed in the "Risk Management" section of the "Configure Receiving From". Clicking this new link opens a new "Exposure Limit Monitoring" tab. The resulting tab displays the list of Exposure Limit Monitors that apply to the selected partner.

Exposure Limit Monitoring page
A new FTM Participant Id column has been added to the grid and to the available filters. There is a new Expanded filter section added to the Exposure Limit Monitoring page. The Expanded filter is below the current data filter and toggles between expand and collapse to hide the expanded filter.

Currently, the expanded filter contains a text box for Monitor ID. This Monitor ID field is treated as an "AND" to the current data filter. The Monitor ID field can be entered by itself and the filtered data will display all monitors for that Monitor ID. If the Monitor ID field is completed along with a data filter, the filtered list contains entries that satisfy the data filter AND the extended Monitor ID filter.

Ex.
The filter is selected to be Originator equals John Doe and Monitor ID is set to 5. The filtered data that will be displayed will be the items that have an Originator of John Doe AND a Monitor ID of 5.

85284
Early Warning Services (EWS) V3.9 Mandate

Early Warning Services (EWS) version 3.9 has mandated that cancelled-by-sender is a valid Denial Reason Code. In order to support this, FTM has upgraded multiple EWS messages that it processes from V3.8 to V3.9.

FTM now supports OnPaymentStatusChangeNotification39 from EWS. OnPaymentStatusChangeNotification38 is no longer supported. Once this version of FTM is installed, it is important that you notify EWS to send OnPaymentStatusChangeNotification39 notifications to your system since OnPaymentStatusChangeNotification38 messages will not be processed.

For now, EWS will support cancelled-by-sender for both Denials and Failures, so the cancelled-by-sender reason code is available in both Failed and Denied on the Cancel Zelle transaction dialog box within FTM. The reason code drop-down box is now sorted alphabetically.

72216, 80139
Split Payments

Two new web services have been added to support split payments, which will allow for multiple payment requests (split).

The two new web services are CreateZellePaymentRequest and ReadZelleTransaction. CreateZellePaymentRequest will allow a user to send multiple payment requests in one RESTful web service request to FTM. ReadZelleTransactions has been implemented to eventually allow a user to retrieve any specific Zelle transaction. Currently, only Payment Requests are supported in this implementation. The full documentation for the two new web services is in the Web Service API Reference that resides in the product.

A DeactivateRequestOnAnyAmount field has been included on the new Zelle Payment request web service. If this is set to false (default), a payment request will remain active until the requested amount is paid in full.

If it is set to true, the request will be deactivated whenever any amount is received for the request. If underpaid, the status will be COMPLETED. If paid in full or overpaid the status will be PAID. This allows customer flexibility on how to process payment request deactivations.

This field will be displayed on the Zelle attributes tab of the transaction details.

The UUIDs for the requestorId and requestorDetailsID in a payment request should now be a standard UUID value.

86258
Account closed failures

Previously, incoming Zelle payments that failed the funds transfer user exit would be FAILED with a 'cannot-process-expedited-payment' reason code for real-time payments and a 'unable-to-accept' reason code for non-real-time payments.

Now, to be more in line (not mandated) with the EWS V3.9 spec, incoming payments that fail the funds transfer user exit are DENIED with an 'issue-with-credit-account' reason code.

Migration

The following document contains the instructions that are needed to migrate from V3.0.6, Fix Pack 3 to V3.0.6, Fix Pack 4:

FTM_ACHServices_V3.0.6.4_Migration.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Back to top	V3.0.6.3 iFix 1

Feature changes

84447
Scheduled Payments user interface - Allow users the ability to Read, Update, Cancel, and Cancel Next

When the correct permission is applied (Application: Admin, Category: Scheduled Payments), the Scheduled Payments UI grid is found by navigating to Configuration->Partners->Scheduled Payments.

This functionality provides user interface support for scheduled payments. Web services for scheduled payments are referred to as recurring payments.

User interface support will include:
- Grid display of all the scheduled payments in the system.
- Ability to view a single scheduled payment with full details in tabular form when the model name is clicked.
- Ability to update the scheduled payment (both active and non-active).
- Ability to cancel the model or cancel the next scheduled payment using action buttons on the grid.
- Create is ONLY available as RESTful web services at this point.

Back to top	V3.0.6, Fix Pack 3 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 2 release.

Compatibility Matrix

In the 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.0.6, Fix Pack 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.0.6, Fix Pack 3, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 14
3.0.2.1	3.0.2.1 iFix 14
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.6.0	3.0.6.0 iFix 5
3.0.6.1	3.0.6.1 iFix 4
3.0.6.2	3.0.6.2

Known issues

None.

Feature changes

76669
Zelle Notification user interface

Two new methods have been added to the Zelle notification user interface (com.ibm.fxh.zel.ui.ejb.sendnotification.service.UserSendNotificationInterface). One to support customer notifications for Zelle token deletions and one to support Zelle participant deactivations.

The delete token notification will only be sent when individual tokens are deleted. The delete token notification won’t be sent when a participant has been deactivated (only the deactivate participant notification will be sent).

The two new methods are:

/**
* This operation is invoked after an FTM Zelle Participant's token has been successfully
* deleted.
* The implementation is responsible for delivering to the internal notification system the
* required details so the internal notification system is able to notify the end bank customer.
*
* @param cxcToken the deleted token to which the message should be delivered.
*/
public void sendTokenDeleted(CXCToken cxcToken) throws CXCServiceException;

AND

/**
* Notification event raised when a Zelle participant has been deactivated.
*
* @param cxcParticipant the participant that has been deactivated.
*/

Skeleton methods have been added to com.ibm.fxh.zel.ui.ejb.sendnotification.service.UserSendNotification.
Sample methods have been added to com.ibm.zel.samples.SampleUXSendNotification.

The two new methods are:

AND

/**
* Notification event raised when a Zelle participant has been deactivated.
*
* @param cxcParticipant the participant that has been deactivated.
*/

Skeleton methods have been added to com.ibm.fxh.zel.ui.ejb.sendnotification.service.UserSendNotification.
Sample methods have been added to com.ibm.zel.samples.SampleUXSendNotification.

81455
Early Warning Services (EWS)
Added support to download the additional "Dispute Account" from the EWS Shared Directory. This required FTM to upgrade to the 3.9 version of getOrganizations() SOAP API provided by EWS. The following outlines the enhancements made:

Early Warning Services specification upgrade
FTM upgraded to use the V3.9 technical specifications to make the getOrganizations() 3.9 call

Database Enhancements
A new ACCOUNT_TYPE database record has been added to support the new "Zelle Dispute Account". (See database migration for more details)

New Dispute Account Records in the user interface
For each organization loaded/updated from EWS Shared Directory, if a Dispute Account was configured, FTM will load and make available in the Partner->Accounts page the new "Dispute Account" information.

SampleUXTransferFunds.java
This user exit sample was enhanced to show how to get access to the new "Dispute Account". To use the new sample, this user exit must be recompiled.

UserTransferFunds.java (Deprecation of Constants)
The super class that financial institutions are expected to extend when writing funds transfer user exit (UserTransferFunds.java) has had its account type constants deprecated. Alternate APIs have been provided to get an accurate set of account types. See SampleUXTransferFunds.java for more guidance.

84601
Scheduled notifications
A new interface has been added to allow for user notifications when changes occur to a user's scheduled payment configuration. The new interface is com.ibm.fxh.zel.ui.ejb.sendnotification.service.UserSendScheduledNotificationsInterface. The com.ibm.fxh.zel.ui.ejb.sendnotification.service.UserSendNotification class provides skeleton (empty) support for the new methods and the Zelle sample user exit (com.ibm.zel.samples.SampleUXSendNotification) provides default behavior for the new methods.

If custom support for these new methods is required, any customer notification user exit should now also implement the new scheduled notifications interface (com.ibm.fxh.zel.ui.ejb.sendnotification.service.UserSendScheduledNotificationsInterface).

The methods that are included in the new user exit are:

   -sendScheduledModelCreated
   -sendScheduledModelCancelled
   -sendScheduledModelEdited
   -sendNextScheduledPaymentCancelled

83570
User interface filters
The grid list pages that have a More > Preference > Show/Hide Columns option will be updated to list the available columns in alphabetical order (ascending). The resulting dialog box can be switched to descending order by clicking the column header.
On these same list pages, any filter dialog that contains a list of columns will have that list sorted in alphabetical order (ascending).

Here is a list of the pages that are known to be affected:
Configuration > System > Calendars
Configuration > System > Settlement Cutoff Days
Configuration > System > Transaction Formats
Configuration > Validation Rules > Error Codes
Configuration > Remediation > Vetting Services
System Management > Notification of Change
System Management > Death Notification
Origination & Receipt > Control Totals
Origination & Receipt > Transmissions
Origination & Receipt > Batches/ICLs > Processing
Origination & Receipt > Batches/ICLs > Inbound
Origination & Receipt > Segments
Origination & Receipt > Transactions
Processing & Remediation > Risk Review > Authorization
Processing & Remediation > Remediation Lock Management
Distribution > Pause/Resume
Financial Management > Settlement > Intraday Balancing
Financial Management > TCR Active Units of Work

The previous behavior of these dialog boxes were that the columns were listed in the order that they appeared on the page.

77304
Actimize
FTM has added support for Actimize to determine that a payment wasn’t determined to be fraudulent (because that is what the originator of the payment verified) but a decision was made to cancel the payment anyways. The following areas of FTM were enhanced to support this new function.

FTM run time (RTPUI_EJB)
- Supports a new Actimize action of 'Cancel_Per_Sender' (case-insensitive)
- Upon receiving this message with 'Cancel_Per_Sender', FTM will cancel the payment but mark the payment as "No Fraud"
- Payment will be canceled with a validation result of "cancelled-by-sender - Client confirmed no fraud. Requested payment to be canceled."

EWS Emulator
- Added a new action to the Actimize feature of 'Cancel (per sender)'

Functional Note
FTM no longer suspends the parent batch of a Zelle payment when payments are identified as "Possible Fraud" or "Pending to unknown recipients". FTM also no longer rejects the parent batch when a fraud operator decides that a payment is fraudulent. This decision provides a more consistent payment processing strategy with other payment types such as NACHA and check.

APAR PH03029
SOAP web services

SOAP web services with RESTful web service equivalents have been removed. The following table contains the SOAP web services that have been removed and their RESTful web service equivalents:

SOAP web services	RESTful web services
listOutboundTransmissions	OutboundTransmissionInfo
listInboundProducts	InboundProductServices
listInboundTransmissions	InboundTransmissionInfo
listInboundBatches	InboundBatchInfo
listInboundTransaction	InboundTransaction
listValidationResults	ValidationResults
listTransmissionTypes	TransmissionType
listBatchTypes	BatchType
listMesssageStandards	MessageStandard
listMessageTypes	MessageType
listBusinessDay	BusinessDate
listPaymentRecordTypes	PaymentRecordType

Migration

The following document contains the instructions that are needed to migrate from V3.0.6, Fix Pack 2 to V3.0.6, Fix Pack 3:

FTM_ACHServices_v3.0.6.3_Migration.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Back to top	V3.0.6.2 iFix 1

No changes.

Back to top	V3.0.6, Fix Pack 2 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 1 release.

Compatibility Matrix

In the 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.0.6, Fix Pack 2, 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.0.6, Fix Pack 2, you must be no higher than version
3.0.0.15	3.0.0.15 iFix 14
3.0.2.1	3.0.2.1 iFix 14
3.0.4.0	3.0.4.0 iFix 3
3.0.4.1	3.0.4.1 iFix 1
3.0.5.0	3.0.5.0 iFix 1
3.0.6.0	3.0.6.0 iFix 3
3.0.6.1	3.0.6.1 iFix 3

Known issues

84427
The DSU import tool will allow IMPORT/EXPORT capabilities for all new recurring payment tables. However, the tool will fail on UPDATEs to the recurring transaction table (Scheduled Zelle Transaction tab).

Feature changes

81157
WebSphere

New WebSphere artifacts are required in version 3.0.6, Fix Pack 2. See Migration below for manual migration instructions from version that are earlier than V3.0.6, Fix pack 2.

When sending Zelle payments to unknown recipients, the participant's address is required. For recurring/scheduled Zelle payments, the participant address will be retrieved from the CXCParticipant information. If the participant wants to send recurring/scheduled payments to an unknown recipient, the participant's address should be stored using the create/update CXCParticipant web services.

When a participant account is closed, any recurring model configurations associated with that account will be canceled.

76719
Zelle

CXCPayment deprecated methods

String getFtmPaymentID() and setFtmPaymentID(String)

The setter and getter methods for FTMPaymentID (as type String) have been deprecated within the CXCPayment object.

If customer written user exits are using these methods, then it’s recommended to use the new getFtmPaymentId() signature (returning type PaymentId).

When moving to use this method, you’ll need to add util.jar to your class path for compilation. However, you won’t need to add util.jar to your sharedLibrary path for RTPUI_EJBEAR as this JAR file is already loaded in its class loader.

New fields in CXCPayment object

Multiple fields have been added to the CXCPayment object for customer use.

PaymentId: The unique identifier (auto-generated ID) for the payment in the database
BusinessDayId: The unique identifier (auto-generated ID) for the business day of the payment
Funds Transferred: Flag identifying whether funds were transferred for this payment.
Funds Reversed: Flag identifying whether funds were reversed for this payment.
Disputed: Flag identifying whether this payment is under dispute.

Database connections available within Zelle user exits

Each of the user exits now have access to a database connection. Customers no longer need to get their own database connection if they are looking to do database work inside a user exit.

Notification Events

The Zelle component has additional notification events.

Funds Reversed
Payment Denied
Recurring Model Failed
Recurring Model Complete
Upcoming Recurring Model

Notification Listing

Notification	Category	Comments
Welcome Message	Token	Raised when a participant’s “First” token is created. Not for subsequent tokens.
Payment Initiated	Payment	When a payment is successfully originated and placed on the shared network Note: This has two options. 1) No payment request attached. 2) With payment request attached (in response to a payment request)
Payment Failed (Sending)	Payment	When a payment fails to originate (never makes it to the shared network.) Note: This has two options. 1) No payment request attached. 2) With payment request attached (in response to a payment request)
Funds Reversed	Payment	When a payment’s funds have been reversed. Raised during the cancellation process of a payment or during the return process. (new event)
Payment Denied	Payment	When a payment has been denied (new event). EWS now differentiates between failed and denied.
Payment Received	Payment	When a payment is received successfully and processed. (OnNewPayment) Note: This has two options. 1) No payment request attached. 2) With payment request attached (in response to a payment request)
Payment Failed (Received)	Payment	When a payment is received but we fail to process. (OnNewPayment) Note: This has two options. 1) No payment request attached. 2) With payment request attached (in response to a payment request)
Payment Delayed	Payment	Payment has been held up because of a fraud review
Payment Expired	Payment	When a payment is expired by our task
Fraud Detected	Payment	Payment has been failed because of fraud
Declined by Recipient	Payment	Payment (manual accept) has been declined by the recipient.
Recurring Payment Failed	Payment and Model	When a recurring payment fails to originate.
Recurring Model Complete	Payment and Model	When the recurring model definition completes
Upcoming Recurring Model	Payment and Model	Notifies the next (upcoming) recurring payment
Payment Request Sent	Payment Request	When a payment request is successfully originated and placed on the shared network
Payment Request Received	Payment Request	When a payment request is received successfully and processed. (OnNewPaymentRequest).
Payment Request “Paid”	Payment Request	When a payment is fully paid due to one or more payments that satisfy the monetary amount on the request.
Payment Request “Complete”	Payment Request	When a payment is asked to be marked “Complete” for any reason. Typically, this comes from the originator by a web service update.
Payment Request “Deactivated”	Payment Request	Gets raised called when a payment request expires or gets declined.

New cancel dialog for Zelle payments

For a customer service representative (CSR), FTM offers the ability to easily find and cancel Zelle payments by using the user interface.

Initiate a cancel from the Inbound Transactions page

image-20180822093457-1

Sample Cancel dialog box for an originating Zelle payment

image-20180822093629-2

Fail a payment

When failing a payment, the CSR will have the option to pick from a list of valid failure reason codes. Only valid failure reason codes can be selected.

Deny a payment

When denying a payment, the CSR will have the option to pick from a list of valid denial reason codes. Only valid denial reason codes can be selected.

Force

By default, this option isn’t checked. This means that if reversal of funds fails during the cancellation process, the cancel process will stop. By selecting the ‘force’ option, the cancellation pushes past any reverse funds issues and forces the continuation of the cancel process.

Note: We don’t plan to force which reason codes a CSR can pick from. As long as it is one of the valid reason codes, the system will allow the cancel to take place. It’s up to the CSR to pick the appropriate reason code based on the situation.

Permissions

New permissions dictating which actions are available to the user (CSR).

Can ‘Fail’ a Zelle Payment
Can ‘Deny’ a Zelle Payment

Examples:

If the “Can ‘Deny’ a Zelle Payment” permission is removed, the user will only get the option of ‘Fail’ in the action drop-down list.
If the “Can ‘Fail’ a Zelle Payment” permission is removed, the user will only get the option of ‘Deny’ in the action drop-down list.
If BOTH permissions are removed, selecting a Zelle Payment and clicking the cancel button generates a WARNING message above the table that states that the user doesn’t have permissions to cancel a Zelle payment.

New cancel dialog box for Zelle payment requests

For a customer service representative (CSR), FTM provides the ability to easily find and cancel payments by using the user interface.

A CSR will use the Inbound Transactions page to find a particular Zelle Payment Request they would like to cancel. The CSR selects the payment request and then chooses the ‘Cancel’ action from the table. The following rules control when the Cancel Payment Request dialog box is opened:

The CSR can only cancel one Zelle Payment Request at a time (No bulk cancellation at this time).
The payment record must be a “Zelle” message standard.
The payment record must be either a “Zelle_PROrig” or a “Zelle_PRRecv” message type.
The payment record can’t have a Zelle Status of “Inactive”.
The payment record can’t have an FTM Status of “Canceled”.

If all of these criteria are met, the Cancel Payment Request dialog box opens. (See below)

Sample Cancel Payment Request dialog box for an originating payment request

image-20180822100051-1

When a payment request is deactivated, the History tab tracks the deactivation process with the appropriate tracking messages.

Sample History tab for payment request deactivation

image-20180822100210-2

Returns processing

The returns process now requires FTM payments to be properly linked using FTM’s “Related Transactions” concept. The “Related Transactions” concept ensures that each payment has been properly linked and reconciled. This means that for the returns process to work correctly, FTM requires the following configuration:

Turn on “Batch Rules Set” to link (Links the received NACHA return record to the originating Zelle record).
Run the Zelle Reconcile Task (Links the NACHA settlement record to the Received Zelle Payment)

image-20180822100529-3

For In-Network returns, the system will reverse the funds and notify the participant but won’t fail and/or cancel the Zelle payment. Because the Zelle payment isn’t failed or canceled, there’s a new notification event to inform the user that the funds were reversed. Previously, the notification raised was “Payment Failed”. FTM has replaced the “Payment Failed” event with a “Funds Reversed” event. This event is only raised if the system reverses the funds.
The following tracking records are currently being recorded for the reverse funds process:
1. Reverse funds started.
2. Reverse funds completed
3. Reverse funds notification sent (New)

Below is a simple set of tables representing the Zelle settlement and return records for both originating and receiving banks and how each payment is related.

Bank who originates payment and receives the return

FTM Payment ID	FTM Status	Message Standard	Message Type	Forward Return	Related Transaction	Orig Seq Number	Alternative ID	Comments
303	Accepted	ZELLE	ZELLE_Orig	Forward		FGB000012377		Originated Zelle Payment
412	Accepted	NACHA	CCD	Return	RETURN_OF 303		FGB000012377	Received Return Item

Bank receives payment and settlement record who initiates a return

FTM Payment ID	FTM Status	Message Standard	Message Type	Forward Return	Related Transaction	Orig Seq Number	Alternative ID	Comments
12377	Accepted	ZELLE	ZELLE_Recv	Forward		FGB000012377		Received Zelle Payment
17789	Accepted Returned	NACHA	CCD	Forward	SETTLEMENT_OF 12377		FGB000012377	Received Settlement Record for 12377 (CSR Clicked Return)
17790	Accepted	Internal	Internal	Return	RETURN_OF 17789		FGB000012377	Generated Return Item

Reversals

When canceling an originating payment that has been previously distributed using Distribution, FTM generates a reversal (NACHA) instead of cancelling the Zelle payment and marks the Zelle payment with an FTM Status of “Reversed”.

The Zelle Payment will contain a “Related Transaction” to the reversal record with a relationship type of “REVERSAL_OF”.

New Inbound Transaction flags ('Funds Transferred', 'Funds Reversed' and 'Disputed')

Three new payment flags have been added to the Inbound Transactions page.

By default, these flags aren’t visible on the Inbound Transactions page but can be added by the financial institution.

The system tracks when funds have been successfully transferred and/or reversed to protect against any possible double transferring or reversing of funds.

Funds Transferred

When funds have been transferred by the Zelle User Exit successfully, the flag will be flipped to Yes. Valid values for this column in the database are "Y" = Yes, "F" = Failed, Blank (Funds not transferred).

Funds Reversed

During the cancellation process, only if the funds were transferred will the system attempt to reverse the funds. If successful, the flag is set to Yes. Valid values for this column in the database are "Y" = Yes, "F" = Failed, Blank (Funds not reversed).

Disputed

This is a flag that can only be flipped manually in the user interface. No back-end processing can flip this flag to Yes or No. Valid values for this column in the database are "Y" = Yes, "N" = No.

Sample view of flags

image-20180822102330-1

Detailed history for a 'Cancel' of payment and payment request

During the cancellation of a payment or payment request, the system now keeps a detailed record of each step of the cancel process. These tracking records can be found on the history tab of a given canceled Zelle payment or payment request.

Sample tracking on a canceled Zelle payment

image-20180822102517-2

CSR ability to manually flip 'Funds Transferred', 'Funds Reversed' and 'Disputed' flags

A CSR needs the ability to manually flip (or toggle) these flags. One typical use case might be when a Zelle payment had funds transferred or reversed by other means, outside of FTM, and the Zelle payment needs to be properly reflected so that FTM doesn’t transfer or reverse these funds a second time. The Disputed flag can also be flipped for record keeping purposes.

The CSR can manually manipulate these flags regardless of the flag’s current state. This is at the discretion of the CSR.

image-20180822102721-3

Processing ‘Out-of-Network’ returns

When the originating bank receives a return file associated with “Out-of-Network” payments, FTM handles this return scenario slightly differently than returns for “In-Network” payments.

If the system receives a return for an “Out-of-network” payment, FTM will fail the payment in EWS. (Out-of-Network payments will never be “Delivered”)

The failure of the “Out-of-Network” payment won’t be canceled in FTM but the system will attempt to fail the payment in EWS.

Key points of interest on the Zelle “Out-of-Network” payment when processing the return item:

The system will attempt to fail the payment in EWS with a “ChangePaymentStatus3.8” SOAP call passing the appropriate “return reason code”.
The system will update the following attributes in the database for the Zelle Payment.
- EWS Status to Failed (assuming the payment could be failed in EWS)
- Return Reason Code (Should be set to R06)
- Zelle Reason Code (should be “ach-return”)
- A Validation Result is added to the Zelle Payment
FTM will bypass the canceling and deleting of the payment in FTM.

Note: Since the system is bypassing the cancel and delete of the payment, the parent batch and transmissions aren’t rejected (because they aren’t deleted in FTM)

FTM sends a notification that the payment has been “failed”.

image-20180822103302-1

Support for EWS SOAP calls for getPayment3.8 and getPaymentRequestDetails3.0

With the asynchronous nature of FTM and EWS, it’s possible to initiate a cancel when the payment is currently being canceled by the receiving bank. To help minimize these in-flight processes, when canceling a Zelle payment or deactivating a Zelle payment request, support was added to make calls into EWS to retrieve the current status of a Zelle payment or Zelle payment request. This enhancement protects FTM from accidentally failing or deactivating EWS payments and payment requests that are already canceled.

Examples:

Protects from failing payments that are already failed in EWS.
Protects from failing payments that are already delivered in EWS.

76663
Asynchronous notification queues (Fraud, EWS, FTM)

For performance purposes, the asynchronous notifications for Fraud, EWS, and FTM are now split into different processing queues. This allows customers the ability to control and optimize the processing of each type of message based on volume.

Rejecting parent records when canceling a Zelle payment

FTM no longer rejects the parent records (batches and transmission) when a Zelle payment is canceled. Since the batches and transmission are no longer rejected, any customers listening for batch or transmission reject events when a payment is canceled may need to adjust their Transaction Server Scheduler event stanzas accordingly.

76951
Recurring payments

Users will be allowed to configure and schedule Zelle payments on a recurring/future dated basis. The user will be allowed to schedule payments for SINGLE, WEEKLY, and MONTHLY recurrences. These recurring payments will be generated on the scheduled recurring date(s) until the configured end date OR the configured number of occurrences is reached.

The Scheduled Payments services framework task (com.ibm.paydir.izg.tasks.scheduledpayments.ScheduledPaymentsTask) should be registered and configured to run on a daily basis. This task will initiate any configured scheduled payments that are scheduled for the day and perform any required notifications.

The application will allow notification user exit entry points to allow the user to be notified of upcoming recurring payments, recurring payments that failed and completed recurring payments (reached its end date). The notifications are detailed in story 76719.

The FTM user interface identifies the payments that were generated by a recurring payment configuration.

There are new webservice APIs available that will create/update/delete the scheduled payment configurations. They are:
•   Create Zelle Recurring Model
•   Read Recurring Models
•   Update Recurring Model
•   Cancel Next Recurring Payment
•   Cancel Recurring Model
•   Read Future Payments

These new APIs are detailed in the Web Service Browser API Reference.

81174
ADU

Two new tokens have been added to the ADU Tokens configuration for support of asynchronous fraud responses and Messaging API messages to isolate the processing of EWS Notifications. When installing the RTP Component, ensure that the following new tokens are properly configured:
IBM MQ Zelle Fraud Queue: New token holding the queue name for asynchronous fraud responses
IBM MQ Zelle AppBridge Queue: New token holding the queue name for Messaging API messages

There have been JAR packaging changes that affect the Zelle_Utilities.jar file. Some user exits, tasks, or both, may now also require util.jar and payment_accessors.jar. Review the pertinent readme files for possible updates.

84578
SOAP web services

The following SOAP web services are being deprecated: Inbound Transmissions, Inbound Batches, and Inbound Transactions. Use the RESTful web services in place of these.

Migration

The following document contains the instructions that are needed to migrate from V3.0.6, Fix Pack 1 to V3.0.6, Fix Pack 2.

FTM_ACHServices_v3.0.6.2_Migration.pdf

Which can be downloaded from Fix Central at 3.0.6-FTM-ACH-MP-Documents .

Back to top	V3.0.6.1 iFix 10

No changes.

Back to top	V3.0.6.1 iFix 9

No changes.

Back to top	V3.0.6.1 iFix 8

No changes.

Back to top	V3.0.6.1 iFix 7

No changes.

Back to top	V3.0.6.1 iFix 6

No changes.

Back to top	V3.0.6.1 iFix 5

No changes.

Back to top	V3.0.6.1 iFix 4

No changes.

Back to top	V3.0.6.1 iFix 3

No changes.

Back to top	V3.0.6.1 iFix 2

No changes.

Back to top	V3.0.6.1 iFix 1

No changes.

Back to top	V3.0.6, Fix Pack 1 Release

Note: This section contains any changes since the V3.0.6, Fix Pack 0 release.

Designation nomenclature:

[ALL] The item applies across the Payment Feature Services (pfs directory) common components.
[ACH] The item only applies to the ACH Services product.

Known issues

Item	Description
80743	Missing setter on PayInsertBean (fixed in V3.0.6.1 iFix 1).
81074	Missing setter on PayInsertBean (fixed in V3.0.6.1 iFix 1).
81106	Zelle Reconciliation Task Fails When Zelle Batch Has More Than One Transaction (fixed in V3.0.6.1 iFix 1).

Feature changes

OnPaymentStatusChange Notification
Starting with V3.0.6, Fix Pack 1, the following versions are supported and are required to be configured with Early Warning Services (EWS).

Notification Version
OnTokenStatusChangeNotification 2.0
OnPaymentProfileStatusChangeNotification 2.0
OnNewPaymentNotification 3.8
OnPaymentStatusChangeNotification 3.8
OnNewPaymentRequestNotification 3.0
OnPaymentRequestChangeNotification 2.4
OnCustomerChangeNotification 2.4

OnNewPayment Notification
Starting with V3.0.6, Fix Pack 1, the following versions are supported and required to be configured with Early Warning Services.

Notification Version
OnTokenStatusChangeNotification 2.0
OnPaymentProfileStatusChangeNotification 2.0
OnNewPaymentNotification 3.8
OnPaymentStatusChangeNotification 3.8
OnNewPaymentRequestNotification 3.0
OnPaymentRequestChangeNotification 2.4
OnCustomerChangeNotification 2.4

Debit Card Business Rules Updates
Sample DSU spreadsheet values are provided to support a default Visa/Mastercard ingestion/process.

Mastercard Debit Card File Ingestion
Implemented a new Mastercard file reader which will ingest a Mastercard file (Mastercard Send Domestic Service Reconciliation Report). The ingested transactions will be of a MC_DAILY message type and the transactions will be linked to a Mastercard DNA account that will be configured for the receiving partner. The Mastercard file will contain both credits and debits, and there will be a single net settlement transaction (M_NET_SETTLE) created for the file. This net settlement transaction will be linked to the Mastercard Net Settlement account configured for the receiving partner.

There will be user exit entry points that will allow some flexibility in determining the transaction type (credit/debit) of each item as well as the value of the alternative ID (the identifier that will match the EWS value for the same transaction).

Visa Debit Card File Ingestion
Implemented a new Visa file reader which will ingest a Visa file (Visa Raw Data Records). The ingested transactions will be of a VISA_DAILY message type and the transactions will be linked to a Visa DNA account that will be configured for the receiving partner. The Visa file will contain both credits and debits, and there will be a single net settlement transaction (V_NET_SETTLE) created for the file which will be associated with all of the VISA_DAILY transactions. This net settlement transaction will be linked to the Visa Net Settlement account configured for the receiving partner.

There will be user exit entry points that will allow some flexibility in determining the transaction type (credit/debit) of each item as well as the value of the alternative ID (the identifier that will match the EWS value for the same transaction).

EWS Debit Card Reader Changes
The debitNetwork.transactionId for each accepted EWS transaction is now stored so that it can later be reconciled with the corresponding Visa/Mastercard transaction.
That field ("Alternative ID") will be available on the Transaction grid as well as the details.

Added the ability to ingest "declined" EWS transactions (as DCARDR transactions) and assign a declined error code (if configured).

Implemented a new User Exit (with Sample) that will specify:
-whether an EWS item will be accepted
-whether an EWS item will be declined
-whether an EWS item will be ignored
-the transaction type of the EWS item: Credit or Debit
-the "alternative ID" of the item (which is the identifier that the transaction will be known by EWS/Visa/Mastercard)

Removed the Requirement for a Resource Environment Provider
The EndpointConfig configuration in WebSphere Application Server's Resource Environment References shouldn't be a product requirement and should be optional based on the customer's requirement. Therefore the following changes have been made:

1. Customers are no longer required to configure EndpointConfig in their WebSphere Application Server's Resource Environment References.
2. Zelle user exits will now work with or without this configuration.
3. As a result of making this requirement optional, all the method signatures in user exits: SampleUXTransferFunds.java and SampleUXFraudDetection.java are changed. Methods will no longer have 'configurations' HashMap passed down.
4. Customers who are upgrading from a previous release that supported this feature will now have a helper method in the user exits on how to retrieve the custom properties from the configuration. A sample of how to retrieve these properties is provided in each of the user exits.
5. Javadoc information has been upgraded to provide information on the classes that were exposed as part of the SDK.
6. All User Exits will now throw only CXCServiceException. This also resulted in method signature changes in the user exits, notably SampleUXSendNotification.java.

Company Descriptive Date
Zelle payments will default the "Company Descriptive Date" in the ACH batch header for Zelle payments, to the date the payment was initiated and received by FTM. This date will be the current date using the operational time zone set within FTM.

77387
Support for Change Payment Status
FTM now supports 16 failure reason codes and 4 denied reason codes for a Change Payment Status in accordance with the Zelle 3.8 specs. This will upgrade the currently supported 12 failure reason codes and adds support for the denied reason codes.

The RESTful Web Services API input for UpdateCXCPayment will now handle both failed and denied scenarios through ‘failureReasonCode’ and ‘failureReasonDescription’. In the FTM Transactions UI, the ‘Zelle Status’ column will now reflect if the payment is Failed/ Denied and a validation result will be added to the transaction. Setting ‘failureReasonCode’ and ‘failureReasonDescription’ will make ‘status’ a required field.

FTM will now handle a Failed/Denied payment status change request from RESTful Web Service and OnPaymentStatusChangeNotification3.8 from EWS and makes sure the Failed/Denied status change is valid.

Debit Card Reconciliation Task
The new Debit Card reconciliation task reconciles debit card transactions in the EWS EOD file with VISA/Master (VISA_DAILY/MC_DAILY) card file transactions.

Misc. Changes
The Expire Payments SF task now has an additional configuration parameter called "Message Type". The default value, ZELLE_Orig will cause the task to behave the same way as it has before this change, while setting the value to ZELLE_PROrig will cause the task to expire Payment Requests instead of Payments.

Added support for level 3 of Payment Request.

Added Zelle Tab to inbound transaction hierarchy to display Zelle related data.

Several Core Properties were added to drive product subscriptions.
Control Center: Components > Zelle > Properties:

Payment Request Origination Product Code
Payment Request Receipt Product Code
Payment Request Expiration Time

Back to top	V3.0.6.0 iFix 5

No changes.

Back to top	V3.0.6.0 iFix 4

No changes.

Back to top	V3.0.6.0 iFix 3

No changes.

Back to top	V3.0.6.0 iFix 2

No changes.

Back to top	V3.0.6.0 iFix 1

No changes.

Back to top	V3.0.6, Fix Pack 0 Release

Note: This section contains any changes since the V3.0.5 release.

Designation nomenclature:

[ALL] The item applies across the Payment Feature Services (pfs directory) common components.
[ACH] The item only applies to the ACH product.

Known issues

SchedulerReference.xml
The inPaymentStandard parameter of the Distribution Profile - Payment Ready - ACH, CPS event was missing a "!8" that was causing Zelle payments to be sent to distribution early despite not being marked Zelle complete (fixed with V3.0.6.0 iFix 3 - 80541).

Feature changes

The minimum FTM Base version supported is now V3.0.0, Fix Pack 7.

The minimum WebSphere Application Server Java version is now Java V7, with Java V8 also being supported.

Installation location
The product will be installed in a V306 subdirectory. For example:

Instead of {install location}/xxx/v305 will be {install location}/xxx/v306 where xxx is ach.
Instead of {install location}/shared/v305/pfs will be {install location}/shared/v306/pfs.

Migration from release V3.0.5.0 to release V3.0.6.0
The "Update procedure" fix pack instructions also apply to migrate from V3.0.5.0 to V3.0.6.0.

If the FTM Base product used for creating the database is less that V3.0.0, Fix Pack 7 you’ll need to migrate the database up to the minimum supported Base version.

Risk Monitors

For Risk monitors that apply to real-time payments, specifically basing them on business days (skipping weekends and holidays) isn’t feasible. Unlike ACH transactions, the real=time payments can and will be received on non-business days.

A new configuration option for risk monitor definitions has been implemented that will determine if the configured monitor will be based on business day or the current day (the day that the transaction was received). The monitor limits will be calculated for each monitor based on this configuration.

Risk Tasks

Previously, the Zelle implementation performed specific Risk-related processing. The details used in this processing came from specific Zelle core properties. With the addition of global monitors, these specific Risk tasks are no longer needed. The core properties that were used have been removed from the database and the user interface.

New Web Service

A new webservice was introduced that will show monitors and limits for a given Partner ID. It will also provide a summary of these monitors and limits, which includes the exact amount of money that can be sent at one time through a batch or transaction, or that will be allowed by the currently active monitors.

User Interface (UI) Updates

A new UI was created within the Global Monitor UI for changing debit or credit limits automatically. This UI allows the user to configure a certain set of conditions that will change credit or debit limits when the conditions are met.

Four new fields were added to the Partner Attributes screen: Customer in Good Standing, when they entered that standing, VIP, and Start of Bank Relationship. These fields are used to further describe the attributes of the partner. Four new fields were also added to the Exposure Limit Monitoring screen for total lifetime count and value of debits and credits that have been processed by a monitor. All of the fields can be used when configuring limit change conditions on the new Global Monitor screen.

The Exposure Limit Monitor screen has been changed to support and show the new global monitors in addition to the pre-existing partner-specific monitors.

New base status is added in the transaction record detail of the transmission hierarchy screen.
The base status indicates the latest status determined by the FTM base product. That is, Immediate Payment status will be provided in the base status attribute.

Providing the ability to deactivate a Zelle participant and a Zelle profile(Token) from the FTM administrator screens.

Additional Info:
Deactivate Zelle participant ability is added to Manage Partners Screen (Configuration > Partners > Partners).

Deactivate Zelle Profile (Token) ability is added to Zelle Participant Attributes Screen (Configuration > Partners > Partner > View Details > Zelle Network Attributes(Under Configure General).

Deleting a partner will now completely remove additional characteristics of a partner such as if they are a Zelle participant.

New APIs

Enhancements to FTM which replaces the changeTokenStatus33 with the newer API's of registerToken38 and unregisterToken36. The new registerToken38 API requires firstName to be provided and almost always lastName.

A new Global Limit Monitors screen was implemented to create monitor definitions that can apply to many partners at once. Within this new screen is another new screen for change conditions, which allow automatic changing of limits if partners meet the configured conditions.

Enhanced FTM to use the new getOrganization38 API that supports the new Organization Type for Network Operator which allows Early Warning Services (EWS) to be assigned as the Network Operator organization.

Enhanced FTM to use the new addPayment38 API for sending payments to EWS. This enhancement was required to support the new Address data for sending payments to unknown and debit card recipients. When supplying an address, the address now requires a 3 character ISO-3166-1Country Code field.

Enhancements to FTM to use the new matchRecipient38 API when making calls to EWS.

Global Monitor

The Risk runtime was updated to account for global monitor definitions in the RISK_MONITOR_DEF table. Any global monitor will be applied to all transactions that meet the criteria defined in the global monitor including limit change rules. The global monitors and the partner-specific monitors will be applied to all payments that meet the configured criteria.

Account Update Message

A new account update message was created so that Transaction server can close or open a partner account. Then, any application that needs to be notified of this account update can be notified (by the scheduler.xml). For the current Zelle application, closing account will cause any Zelle token associated with the closed account to be deleted.

Misc.

ChangePaymentStatus - Standard Payment to Expedited for Unknown Recipient.

ChangePaymentStatus3.0 to ChangePaymentStatus3.8 upgrade.

Prevent payment transition from 'Delivered' to 'Failed'.

Related Information

FTM hardware and software requirements

FTM documentation in IBM Knowledge Center

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSPKQ5","label":"IBM Financial Transaction Manager"},"Component":"IBM Financial Transaction Manager for ACH Services","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}],"Version":"3.0;3.0.6;3.0.6.0;3.0.6.1;3.0.6.2;3.0.6.3;3.0.6.4;3.0.6.5;3.0.6.6;3.0.6.7;3.0.6.8;3.0.6.9;3.0.6.10;3.0.6.11","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Tips

Financial Transaction Manager for ACH Services V3.0.6 Release Information

Fix Readme

Abstract

Content

Notification Events

New cancel dialog for Zelle payments

Related Information

Was this topic helpful?

Document Information

UID

Share your feedback

Need support?