V3.2.6 Release Information for Digital Payments

Back to top

3.2.6.1 interim fix 7

Known Issues

None.

---

Feature changes

None.

---

Migration

None.

Back to top

3.2.6.1 interim fix 6

Known Issues

None.

---

Feature changes

None.

---

Migration

None.

Back to top

3.2.6.1 interim fix 5

Known Issues

None.

---

Feature changes

None.

---

Migration

None.

Back to top

3.2.6.1 interim fix 4.2

Known Issues

None.

---

Feature changes

None.

---

Migration

None.

Back to top

3.2.6.1 interim fix 4.1

Known Issues

None.

---

Feature changes

None.

---

Migration

None.

Back to top

3.2.6.1 interim fix 4

Known Issues

127798
When using the Request For Return Of Funds web service, Digital Payments was not finding the correct Transaction ID to perform the action against.

Use the following file to insert values:

3.2.6.1_ifix4_127798.ddl

Which can be downloaded from Fix Central at 3.2.6-FTM-DP-MP-Documents

---

Feature changes

None.

---

Migration

None.

---

---

         
 

Compatibility Matrix

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

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 3.2.6, Fix Pack 1, 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 3.2.6.1, you must be no higher than version
3.2.6.0	3.2.6.0

---

Web services exception handling issue


There is a known issue with the web services exception handling, which is expected to be resolved in a follow-on release. Changes need to be made to the exception handling framework that affects all web services APIs. After it is resolved, the exception handling signatures and the data returned will change. Customers who care about the exception response information will need to accommodate the changes.

 

WebSphere Application Server Liberty Update


FTM Base installation includes an updated WebSphere Application Server Liberty v20.0.0.12.  You are recommended to upgrade to this version or a later version if one is available.

86285
Web Services: Business Rules API for Account Edits


A new Business Rules workflow web service was added to perform traditional validation report. This web service runs in WebSphere Application Liberty Server with an IBM JRE that is at IBM Java 8 or later.

The client has the flexibility to configure and deploy the application by modifying the default server.xml or bootstrap.properties. The bootstrap.properties provides a place holder to point to FTM Java Platform, Enterprise Edition Business Rules.

To use the new Business Rules workflow web service, use following URL and request format:

This is a POST request that requires an input in body as following description.
The workflow name can be any valid Business Rules work flow. For example, AchWorkflow, TchWorkflow, CheckWorkflow and others.
The init_requests.fields will be used to create the unique Business Rules Server connection.

Following are the valid init_requests.fields attribute names.

-ibmSortPattern for sort pattern
-ibmPassPktHist for pass pocket history
-ibmFileName for file name
-ibmNprBdDate for business day
-ibmNprBdCategory for business day
-ibmNprPaymentScheme for business day

The ibmNprBdDate is required if ibmNprBdCategory or ibmNprPaymentScheme is used.


The valid decision_requests.fields name can be found in the FTM online documentation.
See the Business Rules User's Guide section under Payment Feature Services.

Use following example: Make sure Fields are updated as the validation is required.

{
  "init_request": {
    "workflow": "AchWorkflow",
    "fields": [
      {
        "name": "string",
        "data": "string"
      }
    ]
  },
  "decision_requests": [
    {
      "fields": [
        {
          "name": "string",
          "data": "string"
        }
      ]
    }
  ]
}

Expected response sample:

{
  "decision_responses": [
    {
      "validation_checks": [
        {
          "error_code": "ACT5001BRA",
          "reject_record_level": "Transaction",
          "override": true,
          "threshold": true,
          "revalidate": true,
          "actual": "Actual Records",
          "description": "Validation Description",
          "record_seq_num": 12345,
          "detail_message": "Validation Detailed Message",
          "record_type": 10,
          "record_seq_to_display": 12345,
          "record_level_to_display": "Transmission",
          "priority": 1,
          "original_reject_record_level": "Batch"
        }
      ],
      "fields": [
        {
          "name": "string",
          "data": "string"
        }
      ]
    }
  ]
}
The generic web service does not validate the data format of each ibmNprXXXX attribute name and values. The value is used as-is in Business Rules Server and, if an invalid request is used, the exception is logged in the Business Rules Server.

This service can be used to retrieve the retry configuration based on the retry process category name, the reason of failure, and the number of retry attempts.

use the following sample curl to invoke the web service.
URL:  <<Server Host>>/businessrules/workflow/retyrconfig

Note that this web service is POST.

{
  "payment_scheme": "TCH RTP",
  "category": "TCH_FROM_CSM",
  "reason_code": "NARR",
  "retry_number": 1,
  "reason_additional_info": "String",
  "reason_originator": 123123123,
  "customer_bank_code": 987654320,
  "customer_account_number": 121212121212
}
Try some combination of input:
For example, invalid category name - notice exception is returned from rules.

Expected response example:
{
  "retry_configured": true,
  "retry_interval": 1800
}


Following are the detailed description of each attribute that is used in the retry config web service.

Category – Retry Category.
Reason Code – Failing processes reason code.
Reason Additional Info – additional reason information (future use). 
Reason Originator – Bank Code of FI who sent the reason code.  For example, if a TCH payment was sent to Bank A and then sent back a pacs.002 msg with a NARR reason code, this would be the Bank A bank code. (future use).
Retry Number – the current retry number – in the case of the first failure – this will be 1 (not 0).  
Customer Bank Code – for an outgoing TCH credit this identifies the originator’s FI (debtor); for an incoming TCH credit this identifies recipient’s FI (creditor) (future use).
Customer Account Num – for an outgoing TCH credit this identifies the originator’s FI (debtor); for an incoming TCH credit this identifies recipient’s FI (creditor) (future use) .

115787
Web Services: Get Retry Configuration - Wrapper the generic BRS WS and create GetRetryConfig BRS WF


New Retry web service is added. Run the Retry web service by providing Payment Scheme, Retry Category, Reason Code, and Retry Number. Make sure a response is returned whether the retry is configured or not (ibmRetryConfigured='true' or ibmRetryConfigured='false'). If retry is configured, it should also return retry interval as configured in Business Rules.


Access <<Server Host>>/openapi/ui
Note: The new Business Rules Services section is displayed with Retry Config web service. (POST method)

This service can be used to retrieve the retry configuration based on the retry process category name, the reason of failure, and the number of retry attempts.

Use the following sample curl to invoke the web service.

{
  "payment_scheme": "TCH RTP",
  "category": "TCH_FROM_CSM",
  "reason_code": "NARR",
  "retry_number": 1,
  "reason_additional_info": "String",
  "reason_originator": 123123123,
  "customer_bank_code": 987654320,
  "customer_account_number": 121212121212
}

Try some combination of input:
For example, invalid category name - notice exception is returned from rules.

Expected response example:
{
  "retry_configured": true,
  "retry_interval": 1800
}

Note: Required and built-in attributes used by the Business Rules retry category web service are payment scheme, category, reason code, and retry number only.

All others can be used if the custom business rules are used to include such attributes (for example, customer account number or bank number). These optional fields are free-form text fields and must conform to the custom business rules. If they are used without a custom Business Rules Server, they are ignored.

RetryConfigWorkflow was added to Business Rules workflows, which is to be called from Retry web service, to determine whether the retry is configured. It also returns the retry interval value configured for each payment scheme and category.

The retry configuration is stored in one of the Business Rules tables that is called RETRY_CONFIG. A Business Rules view RETRY_CONFIG_V that is created from the RETRY_CONFIG table is used by the RetryConfigWorkflow to look up the retry configuration for the parameters that are provided by retry web service call.

The following sample RetryConfigWorkflow, node, task, and data descriptor are added for reference and can be modified by the customer as needed.

Workflow:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowDescriptor name="RetryConfigWorkflow">
<assignments>
  <assignment field="ibmNprPaymentScheme"          type="string" value="" executionPoint="onEntry" conditions="notCurrent" />
  <assignment field="ibmRetryCategory"          type="string" value="" executionPoint="onEntry" conditions="notCurrent" />
  <assignment field="ibmRetryReasonCode"        type="string" value="" executionPoint="onEntry" conditions="notCurrent" />
  <assignment field="ibmRetryAddReasonInfo"     type="string" value="" executionPoint="onEntry" conditions="notCurrent" />
  <assignment field="ibmRetryReasonOriginator"  type="string" value="" executionPoint="onEntry" conditions="notCurrent" />
  <assignment field="ibmRetryNumber"            type="string" value="" executionPoint="onEntry" conditions="notCurrent" />
  <assignment field="ibmRetryCustBankCode"      type="string" value="" executionPoint="onEntry" conditions="notCurrent" />
  <assignment field="ibmRetryCustAcctNum"       type="string" value="" executionPoint="onEntry" conditions="notCurrent" />
  <assignment field="ibmRetryConfigured"        type="string" value="N" executionPoint="onEntry" />
  <assignment field="ibmRetryConfigured"        type="ReturnToClient" value="'Y'"/>
</assignments>
<nodes>
  <node name="RetryConfigNode" />
</nodes>
</workflowDescriptor>

Node:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<nodeDescriptor name="RetryConfigNode" type="ESORT">
<assignments>
   <assignment field="ibmRetryConfigured" type="string" value="Y" executionPoint="onExit" results="SUCCESS" />
   <assignment field="ibmRetryInterval"   type="ReturnToClient" value="'Y'" executionPoint="onExit" results="SUCCESS" />
</assignments>
<tasks>
  <task name="RetryConfigTask" />
</tasks>
</nodeDescriptor>

Task:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<taskDescriptor name="RetryConfigTask" type="TABLE">
<dataName>RetryConfigTable</dataName>
</taskDescriptor>

Data Descriptor:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<dataDescriptor name="RetryConfigTable" type="TABLE">
<fileName>RetryConfigTable.tbl</fileName>
<viewName>Retry_Config_V</viewName>
<record>
  <field datatype="char" length="60" name="ibmNprPaymentScheme"  type="key" />
  <field datatype="char" length="32" name="ibmRetryCategory"     type="key" />
  <field datatype="char" length="64" name="ibmRetryReasonCode"   type="key" />
  <field datatype="byte" length="2"  name="ibmRetryNumber"       type="startKeyRange" />
  <field datatype="byte" length="2"  name="ibmRetryNumberHigh"   type="endKeyRange" />
  <field datatype="byte" length="4"  name="ibmRetryInterval"     type="payload" />
</record>
</dataDescriptor>
 

115789
Retrying payment User Interface updates


Updates were made to allow certain payment error codes to be retried based on Business Rules configuration.  A payment can stay in “Retrying” for a variable amount of time (configurable via Business Rules), so it is important to be able to determine when a payment is being retried.

The Transactions UI pages were updated with a new “Retrying” column that indicates (Yes/No) whether a transaction is being retried.

A Retrying column was added (displayed based on user preference) to the inbound transactions grid.

Inbound Transactions grid


The Retrying column will be available on the transaction grid filter to allow for searches on transactions that are/are not being retried.

Transaction grid filter


The Retrying field will also be displayed on the General (Attributes section) tab of the transaction details UI page.

Transaction details



 

Compatibility Matrix

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

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 3.2.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 3.2.6, you must be no higher than version
3.0.2.0	3.0.2.0 interim fix 2
3.0.2.1	3.0.2.1 interim fix 21
3.0.4.0	3.0.4.0 interim fix 3
3.0.4.1	3.0.4.1 interim fix 1
3.2.0.0	3.2.0.0 interim fix 1
3.2.0.1	3.2.0.1 interim fix 2
3.2.1.0	3.2.1.0 interim fix 3
3.2.2.0	3.2.2.0 interim fix 5
3.2.2.1	3.2.2.1 interim fix 3
3.2.3.0	3.2.3.0 interim fix 4
3.2.4.0	3.2.4.0 interim fix 2
3.2.5.0	3.2.5.0

---

117185 
Fail to correlate remt.001 to pain.013


When a return payment web service is issued by Digital Payments, the transaction only appears in the Inbound Transaction page as a nonpayment transaction. Currently this will not display in the Digital Payments Outbound distribution page. However, the returned payment is sent to the creditor correctly. 

 

112463
Payee management enhancements (Recipients and Recipient Accounts)


New recipient fields will be stored to allow for more detailed information and descriptions about the recipient and their accounts.  

The new fields being added are:

•    Recipient nickname
•    Recipient payment scheme preference
•    Recipient payment message type preference (Should only be used for future NACHA processing)
•    Recipient notification preference
•    Recipient account name
•    Recipient account bank name

Web service integration

New or updated web services:

The following new web service APIs are available for Recipient Accounts.

The available Recipient Account web services are:

•    POST (/pfs/participant/recipient/{ftm_recipient_id}/account) Creates a recipient account for specific recipient.
•    GET (/pfs/participant/{ftm_participant_id}/recipient/accounts) Reads the Recipient accounts by participant ID. 
•    GET (/pfs/participant/recipient/account/{ftm_recipient_account_id}) A specific Recipient account by the recipient account ID.
•    GET (/pfs/participant/recipient/{ftm_recipient_id}/accounts) All the accounts tied to a specific recipient.
•    PUT (/pfs/participant/recipient/account/{ftm_recipient_account_id} ) Updates a recipient account by the recipient account ID.
•    DELETE (/pfs/participant/recipient/account/{ftm_recipient_account_id} ) Delete a recipient account by recipient account ID.

Additionally, Recipient Accounts can be created using the Create/POST web services for a specific Participant and a specific Recipient.

•    POST (/pfs/participant) Participant create web service.
•    POST (/pfs/participant/{ftm_participant_id}/recipient) Recipient create web service.

Read more about these web services in the OpenAPI web service documentation.

Deprecated web services
 


Recipient details:

The new Recipient fields are displayed on the Recipient details page.  The Nickname field will be displayed in the header of the page.  

A new Preferences tab was added to the Recipient details dialog to display the recipient preference fields:




Recipient Account details

The new Recipient Account fields will be displayed on the Recipient details page under the Accounts tab.




User exits

Any user exit that has access to Recipient and Recipient Account data objects will have access to the newly added fields.
 

115186
Additional attributes for scheduled payments


The following scheduled payment fields were previously read only for both web service APIs and participant directory UI pages.  These fields are now available for update:

•    Participant/Payer account information (account number, bank code, account type)
•    Memo
•    Remittance information (structured number, structured proprietary, unstructured info)
•    Instructions for destination

The participant/payer account information is only able to be updated by using the web service API.

New optional fields are being introduced to the scheduled payments model to allow external control/setting.  

These new fields are:

•    Fraud score
•    Approval Time
•    Approval Status (N/A, Pending, Approved, Rejected)
•    Approval reason (Text field description for why the model was accepted/rejected)
•    Approver ID
•    Approver first name
•    Approver last name

These new fields are only allowed to be updated by using the web service API.

Approval status processing

Model Creation:

If an Approval Status is provided, the only allowed values are: Approved (A) or Pending (P).  A recurring model cannot be created if the approval status is Rejected (R).  

If the supplied Approval Status is Pending, the Approval Time value must be supplied, and that Approval Time cannot be later than the initial initiation time of the scheduled payment.

If the supplied Approval Status is Approved and the Approval Time value is not supplied, then the Approval Time value will be set to the current date/time.

If the supplied Approval Status is Approved and the Approval Time value is supplied, then the Approval Time cannot be later than the initial initiation time of the scheduled payment.

If the initiation date for the scheduled payment is “today”, then the payment will be initiated on creation of the scheduled model IF the approval status is Approved or not supplied (null).  If the approval status of the created model is Pending, then the payment will not be initiated right away.  The initiation of the payment will be done if/when the approval status is successfully updated to Approved.

Model Update:

The Approval fields can only be updated on recurring models that are Active.  Approval field updates will not be allowed on recurring models that have already completed or have already been cancelled.

For the Approval Status field, the valid update values are Approved (A) or Rejected (R).

If the Approval Status is updated to Approved and the Approval Time value is not supplied on the update, the current time/date must be before the current Approval Time field (approval time has expired). If the approval time expired, the web service cancels the recurring/scheduled model and sends the appropriate “model cancelled” notification.  This notification is processed by the customer’s user exit.

If the supplied Approval Status is updated to Approved and the Approval Time value is supplied, the Approval Time cannot be later than the initial initiation time of the scheduled payment.

The current time/date must be before the newly updated Approval Time field (approval time has expired). If the approval time expired, the web service cancels the recurring/scheduled model and sends the appropriate “model cancelled” notification.  This notification is processed by the customer’s user exit.

If the approval status of the recurring model is updated to Approved and the initiation date for the scheduled payment is “today”, the payment is initiated when approved (does not wait until the Scheduled Payments Task executes).

If the Approval Status is updated to Rejected and the Approval Time value is not supplied on the update, the Approval Time value is set to the current date/time.

If the supplied Approval Status is updated to Rejected and the Approval Time value is supplied, use the Approval Time value regardless if it is later than the initial initiation time of the scheduled payment or not.

Scheduled Payments UI pages

General tab:

The remittance information, memo, instructions for destination and fraud score can all be seen on the General tab.  All but the Fraud score field can be updated from the UI.





Approval tab:

A new tab was added to Scheduled Payments dialog box.  This new tab contains all the newly added approval fields.




Scheduled Payments Task

The scheduled payments task was updated to consider the new Approval fields that were added to the scheduled model.

Along with gathering the list of scheduled payments to be initiated, the scheduled payments task will now search for any recurring models that have an Approval Status of Pending and an Approval Time that has passed.  Each of these models will be cancelled and the appropriate “model cancelled” notification will be sent to the user.  This notification is processed by the customer’s user exit.  That user exit will have access to the recurring model information that will now include the approval fields.  So, the customer can customize the notification according to the approval fields if wanted.

Web services updated

Here is a list of the web service APIs that were updated:

•    GET (/ws/svc/readrecurringmodels/:ftmParticipantID) Read Recurring Models
•    PUT (/ws/svc/recurringmodels/:id) Update Recurring Model 
•    POST (/ws/svc/scheduledpaymentmodel/) Create Scheduled Payment Model
 

111966
Add generic ISO 20022/pain.001 as a viable Scheduled 


Payments option

FTM added the ability to support an ISO 20022 payment standard and PAIN001 payment message type scheduled payment for Wire transactions.  The previous “Fedwire” payment scheme was replaced with the more generic “Wire” payment scheme.

There is no built-in FTM IBM Integration Bus application that supports Wire payments.  This newly added functionality will allow Digital Payments to initiate scheduled payments for the generic Wire payment scheme where the customer’s Integration Bus application can then pick up the payments and process as needed.

Web service API updates

Here is a list of the web service APIs that were updated:

•    GET (/ws/svc/readrecurringmodels/:ftmParticipantID) Read Recurring Models
•    POST (/ws/svc/scheduledpaymentmodel/) Create Scheduled Payment Model

The Create Scheduled Payment Model web service was changed to include a required Payment scheme.  This field replaces the previous “Preferred payment types” parameter.  The valid values for the Payment Scheme parameter are any configured payment scheme that has an associated PAIN001 payment message type configured.  With the current configuration, the available payment scheme values are “TCH RTP” and “Wire”.

The Read Recurring Models web service returns the Payment Scheme value configured for the recurring model.

Scheduled Payments UI pages

The header section of the scheduled payments details page contains the configured payment scheme value.



Scheduled Payments Task

The ScheduledPaymentsTask configuration parameters were updated or changed. Previously, the task accepted a Payment Message Standard configuration parameter.  Since there are now multiple payment schemes that support the same message standard (ISO 20022), the Message Standard parameter was removed from the task.  

In its place, a new required Payment Scheme parameter was added.  This parameter must be a valid payment scheme name configured in the system. 



This configuration will allow scheduled payments tasks to be configured for multiple schemes (TCH RTP and Wire) that support the same message standard (ISO 20022).

**NOTE: Any existing Scheduled Payments Task configuration will need to be updated to use the new Payment Scheme parameter (from the previous Message Standard parameter).

Generic IBM MQ Queue

A generic FXR.YOUR.WIRE.Q IBM MQ queue was added.  Within the shipped sample data, this is the IBM MQ queue that a customer’s application would be monitoring for scheduled payment messages generated by Digital Payments.

Custom Wire IBM Integration Bus Application

When the custom IBM Integration Bus Wire application is generated, the DEFAULT_SCHEME value of “Wire” should be set for the custom application row in the APPLICATION database table.

This default scheme denotes to FTM that is the application ID to use when processing the scheduled transactions.
 

99432
Limit Management: Prefunded


In previous releases, a Risk Limit Monitor could be marked as prefunded, or a participant account could be marked as prefunded.  

This release adds the prefunded flag to the participant level. If a participant is marked as prefunded, the Risk prefunded user exit is called for all work originated by this partner.    

The prefunded flag is set on the Participant directory General tab as shown in the following figure.





 

99431
Limit Management: Global Limit of $0 should be possible as a default rule for the system


In previous releases, a Risk Limit Monitor Rule with a credit or debit limit of 0 was treated as a flag to monitor the amount of money the participant is processing, but to not fail any records for a limit overflow.  

Some users want to set a zero amount limit so that they can create a Limit Monitor to stop any work from being processed for a participant unless either the participant has opted out of the rule or another rule that overrides the zero amount limit was created for the participant.   

To provide this functionality, the following changes were made to Risk:

1. Lower the Debit and Credit Limits for Limit Monitor (Both Global and Participant Specific) to allow e a value from -1.  The value of -1 indicates to monitor what the participant is sending, but do no fail any batches or transactions.

2. Change the logic in Risk to include a limit amount of 0 in the rules to be tested.

3. Add ability to override global monitors.  If a participant-specific monitor has the same monitor name, monitor Level, Limit span, Monitor type, monitor type value, and date type as a global monitor, the participant monitor overrides the global monitor such that the global monitor is not to be used for that participant. 

This behavior change also affects the response from the Read RiskLimitMonitorView web service API (GET https://<servername:serverport>/fxh/svc/riskmonitorlimitsviews).  If a participant-specific monitor has overridden a global risk monitor, ONLY the participant-specific monitor is returned in this API since the participant monitor is the only monitor applied.


This change includes a migration script that changes any credit or debit limits that are currently 0 and sets them to -1.