Configuration values

General configuration

Bank and process configuration

Typically, these configuration values need to be changed to values that are appropriate for your environment.

On-us bank codes

Typically, these configuration values need to be changed to values that are appropriate for your environment.

The ONUS_BANK_CODE category is used to define bank codes that, for the purposes of outgoing payments, can be settled internally without interaction with the CSM. Typically, this category is an enumeration of all the BIC or routing numbers for the bank. If these numbers are defined, they are checked against the DEST_BANK_CODE of the outgoing credit transfer transactions. When the BIC or routing numbers match, the prechecks that match the values in the IP_OUTGOING_PRE_CHECK/ONUS key for the value table category IP_PROCESS_ONE_STEP_ACCNT or IP_PROCESS_TWO_STEP_ACCNT are done. This situation typically means that an on-us payment doesn't require a call to the sanction screening service or require a reservation of funds and the CSM interaction is avoided.

Add a new key entry for each bank code. The value can be any non-null value. A null value can be used to disable the bank code from the check.

Duplicate checks

The key values that are set for the category DUP_CHECK_TXNTYPES represent the list of transaction subtypes for messages that require a duplicate check. Deleting or setting one of the values to N, causes duplicates not to be checked for those transaction subtypes. The duplicate check is based on the transaction CID in the FTM database. The duplicate check is done during the validation process. For TCH messages with the duplicate flag set in the business application header, '_RPT' is appended to the transaction subtype. The duplicate check is usually not done for the TCH message because the new transaction subtype is probably not on the list of messages to check.

Repeat transaction value checks

The key values that are set for the category REPEAT_CHECK_TXNTYPES represent the repeat transaction subtypes of messages that need to be checked. For the messages with these repeat transaction subtypes, certain fields in the repeat message must be checked against the same values of the original message. If an entry isn't found for the transaction subtype, the value check isn't done for the repeat transaction. If an entry is found, the list of comma-separated values in the entry are checked against the values in the object selector for the original transaction. If entries are added for more subtypes, a matching entry must exist in the object selector for that subtype. If a value in the repeat message doesn't match one in the original, the message is rejected.

Auxiliary status

Typically, you can use the defaults for these configuration values.

The values set here represent the failed, hold, and passed auxiliary status values for transactions that are used during service and use case processing.

Timeouts

Typically, you can use the defaults for these configuration values.

The key values for this category represent transaction status values. The configuration values represent the timeout interval, in seconds, after which transactions in that status time out. When no entry is provided for one of the wait states, the wait is not retried for that state.

If a credit transfer payment object subtype matches the key value for the TIMEOUT_CHECK_TXNTYPES category, the validation action checks whether the Acceptance Date time of the transaction timed out. The Acceptance Date time is the TXN_TIMESTAMP TXN_PAYMENT database entry. The validation checks by using the configuration value for the IP_CSM_TIMEOUT key in the IP_CONFIG category as the timeout delay. If the transaction timed out, the validation event is raised and an error record is logged. By default, the key is set to IP_FROM_CSM_INSTR for the SCTInst scheme, which means that incoming credit transfer payments are checked.

Limit repeat request to CSM

For various reasons, messages that are sent to the CSM might time out. When a message times out, the default processing is to resend the message after the timeout interval elapses. The timeout behavior is modeled in the FSM for a specific wait state. It uses the IP_OBJ_STATUS_TIMEOUT category, where the key is the name of the waiting status. The timeout interval can be defined as a repeating, fixed interval or as a variable, increasing interval. For more information, see Timeouts.

When limit repeat requests are configured, you can use the MAX_REPEAT_VALUE category to restrict the number of times a request is submitted to the CSM. For this category, the key is the message subtype and the configuration value is an integer that specifies the maximum number of retries to be attempted. When the subtype is not configured or has a null value, the requests to the CSM are re-sent until the service becomes available or operator intervention resolves the problem.

After a timeout, a pending status message can be sent to the channel application to indicate that the process is awaiting completion. The key and configuration value entries in the REPEAT_SEND_PENDING category are used to configure sending pending status messages.

The key and configuration value entries provide the status code and optional description fields that are used to route the pending status message back to the channel. The format of the configuration value entry is <CODE>[/<DESCRIPTION>]. A pending status message has a <StatusCode> element, which has a value of PDNG, and a <StatusReason> element. The <StatusReason> element has <ReasonCode> and <Reason> as its child elements. The <ReasonCode> element has the code part of the configuration value entry as its value. The <Reason> element is optional and has the description part of the configuration value entry as its value.

The mandatory <CODE> from the configuration value entry is mapped based on its length. If it has 1 - 4 characters, the CodeIssuer="ExternalStatusReason" attribute is used for the <StatusCode> element. This attribute causes the ISF to be mapped to the StsRsnInf.Rsn.Cd element in the pacs.002 message. A longer code, such as CUSTOM, is mapped to the StsRsnInf.Rsn.Prtry element of the pacs.002 message.

<TransactionStatus>
   <StatusReason>
      <Reason>No response from CSM for IP_FROM_DBTR_INSTR</Reason>
      <ReasonCode CodeIssuer="ExternalStatusReason">NARR</ReasonCode>
   </StatusReason>
   <StatusCode CodeIssuer="ExternalStatusReason">PDNG</StatusCode>
</TransactionStatus>

<TxSts>PDNG</TxSts>
<StsRsnInf>
   <Rsn>
      <Cd>NARR</Cd>
   </Rsn>
   <AddtlInf>No response from CSM for IP_FROM_DBTR_INSTR</AddtlInf>
</StsRsnInf>

Accounting process models

These key values define the different stages of the one-step and two-step accounting process.

In addition to the predefined service names, the list can contain any custom action that you define. You must adhere to a few simple rules when it is called.

Routing

Typically, you can use the defaults for these configuration values.

Standard FTM routing mechanisms are used. The value table category ROLE_FOR_TXN_TYPE is used to define a Service Participant role for each outbound transaction type. When an outbound transaction is being created, the generic routing algorithm locates the outbound channel from the Service Participant whose role matches that defined for the TRANSACTION.SUBTYPE.

Map configuration

Typically, you can use the defaults for these configuration values.

These entries are used to define message-specific mapping configuration for a channel or mapper that can process multiple message types. Essentially, it allows a common or channel map to be used and have the configuration entries control key attributes such as the mapper, transaction, or message types.

<msgTypeCfg>
   <class>PACS008</class>
   <subType>IP_TO_CSM_INSTR</subType>
   <extendedCfg>
      <name>MASTER_FLAG</name>
      <value>N</value>
   </extendedCfg>
   <pt>
      <class>PACS008</class>
      <subType>IP_TO_CSM_INSTR</subType>
   </pt>
   <mapName>ISFToPacs008Mapper</mapName>
   <type>pacs.008.001.06</type>
</msgTypeCfg>

Finite state machine (FSM)

Typically, you can use the defaults for these configuration values. Changing them might cause the FTM for Immediate Payments FSMs to fail.

These configuration values are used to set the OBJ_CLASS of the status message that is sent back to the CSM in the Incoming Credit Transfer use case. The current scheme is used as the key to look up the configuration value to return and use as the OBJ_CLASS. This category is used to configure whether to wait for a response to the status message or not. Use the OUT_TXN_NOWAIT value when you want to wait for a response. Use the OUT_TXN_NOWAIT_COMPLETE value when you don't need to wait for a response from the CSM. Currently, the EPC key is unused.

Status codes

The key values that are set for the IP_STATUS_CODES category represent ISF status code values for non-CSM status messages that need to be substituted to a more appropriate code value. These value entries can be added to or deleted as necessary. Non-CSM status messages are status messages to channel interfaces.

Outgoing batch throttling

Retry configuration

The FTM for Digital Payments retry API can be used for outgoing payments to support the automatic retry of payments that failed one of its configured precheck services, or are rejected by TCH RTP or the receiving financial institution (FI). This capability might be especially useful when the reason for the rejection is due to a timeout or technical error at the external system.

The decision on whether to retry or not is made by Digital Payments Business Rules. Business Rules determines, based on the reason code, whether to retry, how many times to retry, and how long to delay before a retry is attempted.