Remediation and auxiliary processing workflow
This chapter describes the workflow of remediation and auxiliary processing included in Financial Transaction Manager for ACH Services. The workflow consists of several components, which are grouped in separate stages to mark them as parallel running processes.
The chapter starts with an overview of the components and a general description of related configuration files and their structure. After that, it describes each component from a business perspective and provides information about how to configure and use them to create the wanted system behavior.
This chapter includes the following sections:
5.1 Workflow overview and common configuration tasks
Financial Transaction Manager for ACH follows a processing workflow that consists of the following stages, described in Figure 5-1.
Figure 5-1 Processing Workflow overview
For several of these items, the Transaction Server Task Scheduler must be configured. This configuration can be done by a custom Scheduler XML file that is referenced in a config.properties file in installDir/shared/v300/pfs/ITS/profiles. An example file named config_sample_windows.properties is included with the product in the same directory and can be modified for the product configuration. In the config.properties file, the section that is shown in Example 5-1 should point to the Scheduler XML file.
Example 5-1 Section within the config.properties file pointing to the Scheduler XML file
#
# Scheduler configuration
# =======================
#
# schedulerConfigXml = ../xml/Scheduler.xml
# End to End reference event scheduler
schedulerConfigXml = ../xml/SchedulerReference.xml
The SchedulerReference.xml file is in installDir/shared/v300/pfs/ITS/xml, and can be modified by the administrator of the system. On application start, the config.properties file is passed to the installDir/shared/v300/pfs/ITS/cmd/txstart.bat file as a parameter. This process validates the Scheduler XML against the installDir/shared/v300/pfs/ITS/xml/Scheduler.xsd XML schema to ensure that the product receives a valid scheduler XML format and load up the XML afterward.
The Transaction Server reference scheduler XML holds the IBM Financial Transaction Manager Payment Feature Services Configuration for the reference end-to-end flows.
The IBM Financial Transaction Manager Payment Feature Services includes Financial Transaction Manager for Check, Financial Transaction manager for Corporate Payment Services (CPS), and Financial Transaction Manager for ACH Services.
Each major component section in that file indicates if the events are used for ACH, Check, or CPS. This chapter focuses on ACH.
A valid Scheduler XML file can have the structure shown in Example 5-2.
Example 5-2 Example Scheduler XML structure
<?xml version="1.0" encoding="UTF-8"?>
<SCHEDULER>
<INCLUDE>KEYX</INCLUDE>
<PARAMETERSET>
</PARAMETERSET>
<TASK>
</TASK>
<EVENT>
</EVENT>
<TASK background="yes">
</TASK>
<SECTION include="KEYX" name="Section Name">
<TASK>
</TASK>
<EVENT>
</EVENT>
<SECTION include="KEYZ,KEYW" name="Inner Section Name">
</SECTION>
</SECTION>
<SECTION include="KEYY" name="Another Section Name">
</SECTION>
</SCHEDULER>
The tags that are used in the XML files are explained in Table 5-1.
Table 5-1 XML Tags used in the Scheduler
|
Tag
|
Description
|
|
<?xml...>
|
This tag specifies that this file is an XML document
|
|
SCHEDULER
|
This is the wrapper tag which includes the complete Scheduler configuration
|
|
INCLUDE
|
Specifies SECTIONs to INCLUDE (one keyword per INCLUDE).
These keyword values need to match the SECTION include attribute value or the PARAMETER include attribute value for that section or parameter to be read during the Transaction Server start. Tasks and events that are not inside of a section tag set are not affected by the include tag.
|
|
PARAMETERSET
|
Parameter sets can be referenced in any event stanza by using the PARAMETERREF tag. Multiple PARAMETERREF tags are allowed in a single event stanza. Parameter sets can be useful if parameters are required in multiple event tags and code should not be duplicated.
|
|
TASK
|
Scheduler tasks are defined using this tag set. In Example 5-2 on page 85, the second task specification uses the background="yes" attribute setting. This is what causes the task to run in the background. The default operation is foreground, unless otherwise specified.
A task has a NAME tag and an optional INFO tag.
The EXEC tag contains the Java class that is run when the task is started.
The Java classes are included in the installDir/shared/v300/pfs/ITS/lib/txsvr.jar JAR file.
One or more PARAMETER tags can be defined optional to the EXEC tag.
TIMER can be set to “manual” or to “repeating”. Manual does not require any other tags. If it set to repeating, an INTERVAL and a STARTING tag can be defined.
INTERVAL is able to use millisecs, secs, mins, hrs, days, or businessdays as the dimension.
STARTING is optional and can include a date in standard three-segment format MM/DD/YY. In addition to the date, you can specify an optional time stamp in 12-hour mode (with AM or PM included).
<TASK background="yes">
<NAME>Daily Business Day Pre-Allocation</NAME>
<EXEC>
com.ibm.icpcs.transactionserver.scheduler.PreAllocateBusinessDayTask
</EXEC>
<PARAMETER name="preAllocationCount">7</PARAMETER>
<TIMER type="repeating">
<STARTING>9:50 am</STARTING>
<INTERVAL>1 bday</INTERVAL>
</TIMER>
</TASK>
|
|
EVENT
|
Scheduler events are defined by using this tag set. See Table 5-2 on page 87 for TAGS that can be included in the EVENT tag.
|
|
SECTION
|
The section tag set is used to conditionally include one or more tasks, events, or sections in the scheduler XML that is loaded. This tag set has the following attributes:
•include:
Defines the value that can be used in the INCLUDE tag (noted previously in this table) to activate this section in the scheduler when the XML is loaded.
•name:
The name can be used to identify this section in traces. Using a unique name for each section helps with any problem determination.
|
The tags that can be included into the EVENT tag are shown in Table 5-2.
Table 5-2 Event tags
|
Tag
|
Required
|
Description
|
|
NAME
|
Yes
|
The name is a user-specified string that is used to identify the event in traces. Each event should be given a unique name value for debugging purposes. This tag can appear only once for an event.
|
|
TYPE
|
Yes
|
Event type specification. The valid event types are listed in the IBM Knowledge Center: Financial Transaction Manager for Multiplatforms 3.0.0 → Payment Feature Services → Transaction Server User's Guide → Events and Communication with External Applications, at:
Multiple event types can be specified for a single event.
|
|
EXEC
|
Yes
|
Class name of the event handler called when one of the event types occur. It must handle the event types specified in the type tag and be a predefined event handler. This tag can appear only once for an event.
|
|
INFO
|
No
|
This tag is provided for consistency with the task XML specification.
|
|
PARAMETER
|
No
|
Configuration property values for the specific event handler. The parameter tag has the following attributes:
•name
The name of the event handler parameter that is associated with this parameter tag.
•include
Restrict the event PARAMETER with the include attribute. The parameters within the event are not read during Transaction Server start unless the value in the “include” attribute matches an INCLUDE stanza.
Note: This tag is not available for all of the event handlers.
|
|
PARAMETERSET
|
No
|
A group of one or more parameter tags that is given a name so it can be referenced by event tag sets. This is useful when multiple events need to use the same parameters and their values.
|
|
PARAMETERREF
|
No
|
This tag is used to specify a named PARAMETERSET for the event. The PARAMETERSET must be one that is specified in the Scheduler XML file. Multiple PARAMETERREF tags can be used for a single event.
Note: This tag is not available for event handlers that do not have PARAMETER tags.
|
The usage of these tags is shown in the Example 5-3.
Example 5-3 Tag usage
<EVENT>
<NAME>Risk Profile - Canceled Batch</NAME>
<TYPE>PresentmentColumnChange</TYPE>
<EXEC>
com.ibm.paydir.ima.txsvr.event.appbridge.PresentmentStatesEventHandler
</EXEC>
<PARAMETER name="msgType">performAuthorizationCheck</PARAMETER>
<PARAMETER name="condition">accepted</PARAMETER>
<PARAMETERREF>schedulerReferenceProperties</PARAMETERREF>
<PARAMETERREF>sendToRiskManagement</PARAMETERREF>
</EVENT>
Instead of using PARAMETERREF, it is possible to use:
<PARAMETER name="parmFileName">DistributionProfile.properties</PARAMETER>
Example 5-4 shows the DistributionProfile.properties file and the properties necessary for sending messages to Distribution.
Example 5-4 Properties necessary for sending messages to distribution
jmsQmgrHostname = localhost
jmsQmgrChannel = SYSTEM.DEF.SVRCONN
jmsQmgrPort = 1414
jmsClient = true
jmsQmgrName = FTM.QMANAGER
jmsSendQueue = FXH.DISTRIBUTION.INPUT.QUEUE
jmsReplyQueue = FXH.TRANSSERVER.SYNC.REPLY.QUEUE
jmsReplyTimeout = 2500
destinationID = Distribution
The notation that is shown in Example 5-4 is still supported, but generally use PARAMETERREF.
The following sections give more details about the business background of each component and how it is configured.
5.2 Transmission acknowledgment
After payment ingestion, Financial Transaction Manager for ACH has the option to handle transmission acknowledgment as a task of the Gateway server.
The transmission acknowledgment task automates reporting the status of financial batches between institutions. The financial information arrives in the form of electronic deposit files that are transmitted by financial institutions. An electronic deposit file represents a transmission that contains batches.
A widely used configuration is to create the Transmission acknowledgment file after the inbound Gateway has ingested and loaded the electronic deposit file (LOADED state). This Transmission acknowledgment file is placed into the outbound Gateway source folder and delivered by the outbound Gateway afterward.
There are more options for transmission acknowledgment. For example, if the quality of the financial information is checked, processing options are determined, and the information is saved in a database and managed as it makes its way through the financial accounting system. The transmission acknowledgment task can send reports to the financial institution that sent the electronic transmission. Reports can be sent as the transmission reaches various stages of processing and as errors are corrected. The reports acknowledge to the financial institution that its electronic transmission has been received and is being processed.
The Gateway Server and Transaction Server load the incoming electronic transmission and save the financial information in a database. The Transaction Server can use its Messaging API message protocol to notify external applications when events that pertain to the transmission occur. Transaction Server event handlers can create event messages that are sent to other components, such as the Distribution, Settlement, and Services Framework. The PresentmentGroupEventHandler can be configured to send Messaging API messages as transmissions are loaded into the system, and when their status is modified.
When Services Framework receives a transmission acknowledgment message from Transaction Server on its message queue, it searches its tasks for one that matches the receiving point ID in the message. The transmission acknowledgment task must be configured in the Services Framework before it can be used. For more information, see the IBM Knowledge Center at:
Transmission acknowledgment uses the unique transmission ID to retrieve information about the batches from the database and construct a normalized transmission acknowledgment XML file. The XML file, some routing information, and a signal file are placed into an output directory to indicate that the acknowledgment files are ready to be sent. This file can be converted from the normalized transmission acknowledgment XML into another format by using Extensible Stylesheet Language Transformation (XSLT).
By default, transmission acknowledgment uses Gateway Server to send the acknowledgment, which places the files in the Gateway outgoing directory. When the transmission acknowledgment file set appears in its directory, Gateway Server uses the Transmission Acknowledgment configuration property “Transmission Definition” to deliver the file.
For configuration of the Transmission Acknowledgment, log in to the Control Center and click Administration → System → Properties. Then click Edit and ensure that Bank Name and Instance Name are set as shown in Figure 5-2.
Figure 5-2 System Properties window
Afterward, click Configuration → Inbound → Transmission Types and create or edit a transmission type, so that Send Acknowledgment is set to Yes and Acknowledgment Type is set to Transmission Acknowledgment as shown in Figure 5-3.
Figure 5-3 Edit Transmission Type window
Now, configure the Transaction Server Event Handler by editing the Scheduler.xml file, which is typically in installDir/shared/v300/pfs/ITS/xml/Scheduler.xml. In the SchedulerReference.xml file that is included with the product, there is the event Transmission Acknowledgment, which is not included in any section and is commented out. This event is used for Event Handler Configuration. To use it, it must be included and the comment must be removed, as shown in Example 5-5.
Example 5-5 Using the Transmission Acknowledgment event
<EVENT>
<NAME>Transmission Acknowledgment</NAME>
<TYPE>PresentmentGroupStateChange</TYPE>
<TYPE>PresentmentGroupColumnChange</TYPE>
<EXEC>
com.ibm.paydir.ima.txsvr.event.appbridge.PresentmentGroupEventHandler
</EXEC>
<PARAMETER name="msgType">TaskInitiation</PARAMETER>
<PARAMETER name="states">LOADED,!NOTIF_SENT</PARAMETER>
<PARAMETER name="condition">ACCEPTED,REJECTED</PARAMETER>
<PARAMETER name="notifRequest">TRANSACK</PARAMETER>
<PARAMETERREF>schedulerReferenceProperties</PARAMETERREF>
<PARAMETERREF>sendToAccountingInbound</PARAMETERREF>
</EVENT>
The event is started by the specific event types Presentment group loaded and Presentment group column change. The event handler relays the events to the target queue by using a messaging API message:
com.ibm.paydir.ima.txsvr.event.appbridge.PresentmentGroupEventHandler
The remaining parameters are used to send a message to a specified message queue on which Services Framework is listening.
More details about the parameters can be found in IBM Knowledge Center at:
If a format like XHTML, non-XML, or special XML other than the default XML is required, it can be generated by using XSLT. Transmission acknowledgment provides a sample XSLT file, typically at this address:
installDir/shared/v300/pfs/Gateway/tasks/transmissionacknowledgment/xml/SampleTransmissionAcknowledgment.xsl
More information about configuration details can be found in the IBM Knowledge Center at:
5.3 Risk Management
Risk Management provides real-time financial limit management. It monitors incoming batches and transactions to ensure that they do not exceed specified limits for an originating partner. The following types of limits/monitors can be set up for each originator and the subpartners of the originator:
•Batch limit check:
This action checks that the limit for credit, debit, or both amounts for a single batch of transactions is not exceeded. If this check fails, the batch can be rejected or put into a suspended state based on the configuration of the batch limit.
•Prefunded batch check:
This action checks whether the complete amount of the batch is covered by the specific account at the time of processing. If this check fails, the batch is rejected.
•Batch monitor check:
When Risk Management receives a message indicating that a batch is ready to be processed, it searches all of the monitors defined for the partner. Only the limits for monitors that match the attributes of the batch, such as the inbound message standard or inbound message type, and fall within the effective dates defined by the monitor are checked. If a limit for one of the monitors is exceeded, the error code that is defined by that monitor is used to determine the action to be taken. If limits for multiple monitors are exceeded, each failure is recorded and each error is assigned to the failing batch. If a failing monitor limit does not have an error code defined, the system error code property for the limit exceeded is used. If no default error code property has been defined, a system warning alert is generated.
This action checks the monitors that are defined on a batch level.
•Transaction limit check:
This action checks that the limit of the maximum credit, debit, or both amounts for a single transaction is not exceeded. If this check fails, the transaction can be rejected and marked as overridable based on the configuration of the transaction limit.
•Prefunded account check:
This action checks whether the originating account is marked as prefunded. When generating a transaction for a prefunded account, the funds must be reserved before the transaction is sent. In comparison to prefunded batch check, this happens at the transaction level. If the check fails, the transaction can be rejected.
•Transaction monitor check:
The monitoring is working similar to the batch monitor check. This action checks the monitors defined at a transaction level.
Before a user can configure Risk Management of Financial Transaction Manager for ACH, authorization must be configured.
The Financial Transaction Manager authorization model has groups, users, and permissions. Groups contain users and are granted permissions. When applications are added to the Control Center, they define their own application-specific groups. Table 5-3 shows the groups for Risk Management.
Table 5-3 Risk Management user groups
|
Group
|
Description
|
|
Risk Management Administrators
|
Has access to all of the Risk Management user interface functions. This includes access to the Properties tab for configuring the basic runtime parameters for the Risk Management engine.
|
|
Risk Management Supervisors
|
Contains permissions for managing the daily operations of risk. It includes all actions in the system, such as building transmissions or processing eligible transactions. By default, supervisors do not have the ability to see or manipulate the properties of risk.
|
|
Risk Management Users
|
A read-only group that allows users to view the work processed by risk.
|
A full list of the operations/windows available for each group and permission can be found in the IBM Knowledge Center at:
To view and edit risk properties, the user must be in the Risk Management administrator group. The properties can be changed by clicking Administration → Components → Risk → General and is shown in Figure 5-4.
Figure 5-4 Risk General Properties window
The properties that are required by the Risk Management run time are automatically assigned with a default value. Each default value can be changed by assigning a custom value. The custom value always takes precedence over the default value. Some properties might require validation to ensure that any custom values are entered correctly. Validation is performed when changes are saved. If a property is determined to be invalid, the user interface identifies the property that is invalid by placing a red X beside the Custom Entry field. It also displays an error message that identifies why the custom value is in error at the top of the window.
The general properties window is used for configuring the Risk Management engine. Custom error codes for several error events, the number of days to keep risk monitoring data, the business day close action, and the Java class called if a monitor is designated as prefunded can be configured in that view.
The user interface properties view (click Administration → Components → Risk → User Interface) allows you to define the records per page.
After adjusting general properties, limits and checks for partners can be configured. The view is available by clicking Configuration → Partners → as shown in Figure 5-5.
Figure 5-5 Manage Partners window
The window shows a list of partners and links to the partner details and the audit history. The detail view for each partner is available by clicking the magnifying glass as shown in Figure 5-6.
Figure 5-6 Partner Details window
The configuration of Batch Limits is available in the bottom left corner after clicking Risk Management → Batch / ICL Limits if the partner is marked as originator. A debit, credit, or both batch limit can be set up for multiple inbound message standards, message types, and products. A date range can be specified to allow different limits at different times of the year. For example, you might want a larger limit between December 1 and January 15 for a retail originator over the holidays.
The form includes the fields that are shown in Table 5-4.
|
Note: Required fields are indicated with an asterisk.
|
Table 5-4 Batch Limits fields
|
Field
|
Description
|
|
ID
|
The partner identifier from the partner details window. This is a read-only field.
|
|
Name
|
The name of the partner from the Partner Details window. This is a read-only field.
|
|
Monitor Type*
|
Monitors are defined based on the inbound message standard, message type, or product. Select the type for this monitor.
|
|
Message Standard*
|
(Only available if Monitor Type is Inbound Message Standard)
List of the message standards defined in the system. Select a message standard from the list. To select all message standards, choose All from the list. This field is required when the monitor type is message standard.
|
|
Message Type*
|
(Only available if Monitor Type is Inbound Message Standard)
List of the message standards that are defined in the system. Select a message standard from the list. To select all message standards, choose All from the list. This field is required when the monitor type is message standard.
|
|
Product Subscription*
|
(Only available if Monitor Type is Inbound Product)
List of the subscribed products for this partner. Select an inbound product from this list. This field is required when the monitor type is inbound product.
|
|
Credit Limit
|
The maximum credit amount that this partner can receive. This field is required if the debit limit is not specified.
|
|
Credit Error Code
|
The reject level of this error code determines the action that is performed when a batch exceeds the credit limit. If no error code is specified in this field, the value in the batch limit credit error property is used. An error message is displayed on the user interface if the error code entered for this field is not valid for Risk Management.
|
|
Debit Limit
|
The maximum debit amount that this partner can receive. This field is required if the credit limit is not specified.
|
|
Debit Error Code
|
The reject level of this error code determines the action that is performed when a batch exceeds the debit limit. If no error code is specified in this field, the value in the batch limit debit error code property is used. An error message is displayed on the user interface if the error code entered for this field is not valid for Risk Management.
|
|
Effective Begin Date (mm/dd)
|
The first date of the date range to which this batch limit applies.
|
|
Effective End Date (mm/dd)
|
The last date of the date range to which this batch limit applies.
|
To set a transaction limit, there is a separate view on the Partners Details window that you can reach by clicking Risk Management → Transaction Limits. A single debit, credit, or both transaction limit can be set up for outbound message standards and message types. A date range can be specified to allow different limits at different times of the year. For example, you might want a larger limit between December 1 and January 15 for a retail originator over the holidays.
The Transaction Limit view has the same form fields. The only difference is that the Monitor Type can only be set to Outbound Message Standard or Outbound Message Type and, depending on what is selected, Standard or Type must be specified from a drop-down list.
In addition to Batch Limits and Transaction Limits, Exposure Limit Monitors can also be configured from the Partner Details window. They can be defined by clicking Risk Management → Exposure Limit Monitors.
5.4 Risk authorization
Risk Management provides real-time authorization services for originated transmissions and batches of transactions. These services are used to protect the Receiving Depository Financial Institution (RDFI) from the outside world. The following types of authorization services are supported:
•Authorization filters
Authorization filters are used to accept only those transactions that match the criteria specified in the filter. Authorization filters are defined for a partner and a specific account. Filters can specify the transaction type, such as debit or credit, the message type, company ID or name, and amount. When a transaction for an account that requires authorization checking is received and a matching filter is not found, the transaction is rejected and, based on the configuration, marked as reviewable.
•Blocking filters
Blocking filters are used to reject certain types of transactions. Blocking filters are defined for a partner and a specific account. Filters can specify the transaction type, such as debit or credit, the message type, company ID or name, and amount. If a transaction matches a blocking filter, it is rejected and cannot be reviewed.
•Positive pay records
Positive pay records are used to accept only transactions that match the positive pay record. Positive pay records are defined for a partner and specific accounts. These records can specify the transaction type, such as debit or credit, the company ID or name, and amount. These records can also be specified as recurring. Recurring payments are accepted multiple times, whereas a nonrecurring payment is only accepted once. When a transaction for an account that requires positive pay checking is received and a matching positive pay record is not found, the transaction is rejected and, based on the configuration, marked reviewable.
•Stop pay records
Stop pay records are used to reject a particular transaction. Stop pay records are defined for a partner and specific accounts. These records can specify the transaction type, such as debit or credit, the company ID or name, payable to, serial number, and amount. Stop pay records can also be marked as recurring. If a transaction matches a stop pay record, it is rejected and cannot be reviewed.
As work is ingested into the Financial Transaction Manager database, Transaction Server events notify the Risk Management engine of incoming batches that need to be monitored or checked by the authorization services. Transactions and batches that are rejected and overridable or reviewable, are held or suspended until an operator reviews them and either accepts, rejects, or retries them with higher limits or additional funds available. The Risk Management user interface allows operators to perform this review and modify limits.
After risk settings are defined, the progress of processing and remediation can be viewed in the Control Center. Basically there are three views for doing that:
•Processing & Remediation → Exposure Limit Monitoring
The Exposure Limit Monitor window allows you to view a list of exposure limit monitor records for an originator.
•Processing & Remediation → Risk Review → Suspended
The Suspended Work window allows you to review transactions and batches that exceeded their limits or activity monitors. The UI shows all batches with suspended work that have been activity monitored but have not been risk reviewed, and all transactions that have a risk error associated with them and are still risk reviewable.
•Processing & Remediation → Risk Review → Authorization
This window allows you to review transactions that fail the authorization filter. You can view the transaction details and perform appropriate actions on selected transactions.
5.5 Settlement
Settlement tracks and maintains the real-time financial state of all electronic transactions being ingested and completed by the payment system within the Payment Feature Services infrastructure. Settlement tracks inbound transaction and outbound transaction totals for work that comes into and goes out of Payment Feature Services. This includes incoming batches (from external originators and bank branches that come into Transaction Server and adjustments to those batches) and outgoing transit transactions from Distribution.
The benefit of Settlement is not only in tracking transactions, but in allowing the customer to know which transactions are not in a settled state (out of balance).
Settlement is installed in a Payment Feature Services infrastructure and provides these features:
•A summary total for inbound accepted batches and outbound work
•Totals for inbound batches by individual originators
•Totals for outbound work that was sent or is waiting to be sent, for transit transactions by endpoint
•Totals for outbound work that was sent or is waiting to be sent, for on-us work by endpoint
•Pending totals for work that is expected to be sent, but has not yet been accounted for in the outbound transit or on-us work
•A web-based console user interface for administration, and for querying and providing the Settlement total details
A Settlement console component installs into the Control Center. The console provides views of the data on the accumulators and their positions for Transaction Server and Distribution.
For tracking purposes, accumulators are used for representing the source or target of the transactions. Inbound accumulators represent the source of the transactions. They are a branch or partner. Outbound accumulators represent where the transactions are being sent. They are either a partner’s endpoint for transit transactions or an internal endpoint for on-us transactions.
An accumulator has transaction totals for several positions that represent one or more aspects of the transactions for that accumulator. In all cases, totals are segregated by processing bank and business day. An inbound accumulator has positions for these aspects:
•Inbound accepted: Totals for inbound batches that have been received
•Inbound adjustments: Totals for adjustments to the inbound batches in the inbound accepted position
•Inbound total: Totals for the inbound accepted batches with the inbound batch adjustments applied
Outbound accumulators have positions for these aspects:
•Outbound sent: Totals for what was sent for either on-us transactions or transit transactions
•Outbound ready to be sent: Transit transactions that have been mapped to batches by Distribution. but have not yet been sent
•Outbound held over: Totals for transmissions that did not make the final deadline
•Outbound pending: Totals for the difference between the inbound batch's position and the sent position plus held over position and ready to be sent position
Before the Settlement feature can be used, the Transaction Server must be configured.
5.5.1 Register Events in Scheduler.xml
As described earlier, the Scheduler.xml file is used to configure the Transaction Server task scheduler. The Settlement feature requires you to add new events to that XML file. First, make sure that the parameter sets schedulerReferenceProperties and sendToSettlement are available in that file. They should be by default.
After that, several events can be registered:
•To receive the balanced feed from Transaction Server, the event Settlement – Adjustment is used. It is active in the SchedulerReference.xml file by default.
•To receive the cancel batch feed from Transaction Server, the event Settlement Profile - Canceled Batch is used. It is active in the SchedulerReference.xml file by default.
•To perform the Settlement end of day check, the event Business Day End of Day Check contains the sendToSettlement parameter. It is active in SchedulerReference.xml file by default.
•To receive outbound transmission events from the Transaction Server, the Settlement Distribution - Outbound Presentment Group and Settlement Distribution - Outbound Presentment Group Rerouted events are used. They are active in SchedulerReference.xml by default.
•To receive the prime feed from Transaction Server for Corporate Payment Services and ACH Services, the event Settlement - Prime - ACH, CPS is used. It is active in SchedulerReference.xml by default, but ensure that the <INCLUDE>SETTLEMENT</INCLUDE> tag is set. Otherwise it will be ignored (see 5.1, “Workflow overview and common configuration tasks” on page 84).
More details about how to change the XML configuration can be found in the IBM Knowledge Center at:
Some configuration must be done from the Control Center:
•Click Administration → Components → Settlement → Properties to set general Settlement properties. These properties are paging size (number of records to be displayed on each page), End of Day Balancing Level (indicates whether Settlement should be balanced at the entry or batch level at the end of the day), and End of Day States, which are required for Settlement inbound batches. Possible states are SETTLEMENT_PRIME, SETTLEMENT_REPAIR, and BALANCED.
•In the Configuration → Financial Management → Settlement → Accumulator Group which, which is shown in Figure 5-7, accumulation groups within Settlement can be defined. Each accumulator group can contain numerous accumulators, and a single accumulator can be assigned to more than one group. Accumulator groups contain a unique ID and name. They have a yes/no flag for Extract to indicate whether they should be selected by the extract process and a Comparison Supported flag that indicates whether it supports comparison operations and should participate in the comparison operations in the end of day process. Moreover there is an Is Intraday flag to show whether the accumulator group participates in the intraday process, a summary type, and a sequence order for the intraday summary.
Figure 5-7 Manage Accumulator Groups window
•The manage accumulator windows, which can be accessed in Configuration → Financial Management → Settlement → Accumulator, are used to configure the individual accumulators within Settlement. Only one accumulator can be assigned to each item loaded to the Transaction Server. An accumulator contains a unique ID and name, a type (either regular or offset), an Extract flag like in accumulation groups and a Post flag that indicates whether this accumulator supports the creation of posting transmissions.
•Click Configuration → Financial Management → Settlement → Custom Attributes to display and create custom attributes. Only attributes that are visible at the accumulator level are available. A custom attribute consists of a name, a description, and the type (Group or Accumulator).
•The comparison views windows, available at Configuration → Financial Management → Settlement → Comparison Views, are used to define and manage the comparison views that allow the user to report end-to-end balancing across accumulator groups in Settlement. To define a comparison view, select whether the view should report only the differences that occur when the end-to-end balancing is performed or if all comparisons should be reported even if they balance. One or more accumulator groups must be selected to complete the definition of a comparison view.
After configuring the Settlement Feature, there are several views for using it:
•Clicking Financial Management → Settlement → Inbound → Bank shows the bank view window, which shows the inbound transactions for each bank. Navigate to the accumulator group, batch, and accumulator page for each bank by clicking the drop-down menu on the left of each record in the list. The initial display shows all banks that are available in Settlement. Based on the default settings in the filter, only those banks whose credit total or debit total is not equal to zero are shown. The list can be refined by using the filtering section.
•By clicking Financial Management → Settlement → Inbound → Batch / ICL, you can view the inbound transactions for each batch by a combination of bank and batch ID. Navigate to the accumulator group and accumulator pages for each batch ID by clicking the drop-down menu on the left of each batch record in the list. The initial display shows all of the batches that are available in Settlement by bank and batch ID. Based on the default filter settings, only those batches whose credit total or debit total is not equal to zero are shown. The list can be refined by using the filtering section.
•Financial Management → Settlement → Inbound → Originator shows the inbound transactions for each originator by a combination of bank and originator. Navigate to the batch / ICL, accumulator group, and accumulator window for each originator by clicking the drop-down menu on the left of each originator record in the list.
•The accumulator group view window at Financial Management → Settlement → Inbound → Accumulator Group shows the inbound transactions for each accumulator group by a combination of bank and accumulator group. The main purpose of an accumulator is to allow individual transactions to be grouped for system balancing, monitoring, reporting, and extracting. An accumulator group has one or more accumulators assigned to it.
•The accumulator view window at Financial Management → Settlement → Inbound → Accumulator shows the inbound transactions for each accumulator by a combination of bank and accumulator. The main purpose of an accumulator is to allow individual transactions to be grouped for system balancing, monitoring, reporting, and extracting. Each accumulator contains a dollar total and a transaction count.
•In Financial Management → Settlement → Comparison Views, the comparison windows that were created in Configuration → Financial Management → Settlement → Comparison Views are displayed.
•The distribution management window available at Financial Management → Settlement → Outbound → Distribution Management is used to process any outbound distribution transmissions that were not processed automatically by the events and event handlers. This page displays a list, by business day, of all outbound distribution transmissions that were not processed by Settlement.
•The intraday balancing user interface window in Financial Management → Settlement → Intraday Balancing provides the user with a configurable real-time view of how work is being processed by the Financial Transaction Manager system. Grouping accumulator totals allows the aggregation of accumulators to provide summary information that is meaningful to the way that a financial institution chooses to manage its work.
More information about the user interface for Settlement can be found in the IBM Knowledge Center at:
5.6 Inbound billing
Inbound billing generates billing records for the batches received. As the batches are processed by Gateway, the Business Rules workflow execute node assigns the inbound product code to the batch and assigns a batch billing code to each transaction in the batch. When the transmission is accepted by Gateway, the Transaction Server initiates an event that sends a message to the Services Framework. This message tells Services Framework to run the inbound billing task for the processed batch.
Inbound billing determines whether the batch was already processed. If it was, it is not processed again. If the batch has not been billed, inbound billing accesses the inbound product associated with the batch and determines whether billing is active for the product. If billing is active and the product has billing codes defined, inbound billing generates transmission and batch billing records. It also generates a summary transaction billing record for each transaction billing code in the batch. Multiple transaction billing records can be generated for a batch because each transaction in the batch is assigned a billing code.
At the start of each new business day, inbound billing is called. At that time, inbound billing looks for all customers that subscribe to an inbound product that has a daily billing code. It generates a billing record for each subscribed customer with the inbound product found. This process is repeated for all subscription services in a product.
Inbound billing can be run manually. When it runs manually, it looks for all inbound batches that are not yet processed and submits a request to Services Framework to process them. For more information about running inbound billing manually, see the Services Framework User's Guide in the IBM Knowledge Center at:
Inbound billing can also participate in end of day processing. When inbound billing is called by Services Framework as part of an end of day query, it checks that inbound billing for the business day has been completed for batches whose state matches the prerequisite state defined within the task configuration, and whose associated product has billing enabled. If one or more batches have not been processed, inbound billing reports to Services Framework that it is not ready for end of day processing and lists the batch IDs it has not processed. The operator can run inbound billing manually to process the missed batches.
Inbound billing also logs a message that indicates whether the end of day check passed or failed.
If a batch that has been received into the system is being sent back, inbound billing attempts to remove all records for that batch from the billing table. If the record has already been extracted, it is not removed from the table. Inbound billing informs the Transaction Server of all records that cannot be removed.
For inbound billing to be notified of a cancel batch request, the Transaction Server must be configured to use Services Framework to send a message to the inbound billing task when a batch needs to be canceled. There is an example event defined in the Transaction Server SchedulerReference.xml file that shows a typical configuration to set up event reporting called Billing Inbound – Canceled Batch. It should be active by default as shown in Example 5-6.
Example 5-6 Example event
<EVENT>
<NAME>Billing Inbound - Canceled Batch</NAME>
<TYPE>PresentmentColumnChange</TYPE>
<EXEC>
com.ibm.paydir.ima.txsvr.event.appbridge.PresentmentStatesEventHandler
</EXEC>
<PARAMETER name="msgType">cancelBatch</PARAMETER>
<PARAMETER name="condition">canceled</PARAMETER>
<PARAMETERREF>schedulerReferenceProperties</PARAMETERREF>
<PARAMETERREF>sendToBillingInbound</PARAMETERREF>
</EVENT>
To automate inbound billing processing as batches enter the system, the Transaction Server can be configure to alert the inbound billing task of specific batch events. Example 5-7 shows a typical configuration using the Transaction Server SchedulerReference.xml file to set up the requisite event reporting.
Example 5-7 Example for requisite event reporting
<EVENT>
<NAME>Inbound Billing</NAME>
<TYPE>PresentmentStateChange</TYPE>
<EXEC>
com.ibm.paydir.ima.txsvr.event.appbridge.PresentmentStatesEventHandler
</EXEC>
<PARAMETER name="msgType">TaskInitiation</PARAMETER>
<PARAMETER name="presStates1">REVIEWED</PARAMETER>
<PARAMETER name="condition">ACCEPTED</PARAMETER>
<PARAMETER name="jmsUserId">pduser</PARAMETER>
<PARAMETER name="jmsPassword">pduser10</PARAMETER>
<PARAMETERREF>schedulerReferenceProperties</PARAMETERREF>
<PARAMETERREF>sendToBillingInbound</PARAMETERREF>
</EVENT>
More details about configuring the inbound billing event can be found in the IBM Knowledge Center at:
5.7 Distribution
Distribution is one of the Payment Feature Services components that allow you to create outbound transmissions from data in the Financial Transaction Manager database. Distribution uses the definitions of banks, partners, endpoints, transmission definitions, and building options to control the contents and the type of transmission that is built. Transactions are assigned to transmissions based on the business day, bank, and endpoint that were assigned to the payment at ingestion.
The Distribution engine’s purpose is to build transmissions with batches for sending to receiving points. During ingestion, the receiving point endpoint is assigned to each transaction. The Transmission Definition and Building Option that are part of the receiving point endpoint configuration determine how Distribution builds the transmission file and what transactions are included in the batches. The Distribution engine builds the physical outbound ACH file and copies it to the Gateway's outbound source folder. The Gateway routes the outbound file based on the channel definition.
For memo posts for on-us transactions to internal applications, use the Financial Transaction Manager to create and deliver the memo post files. The Distribution engine creates the logical data structure for multiple types of transmissions. Distribution then sends a WebSphere MQ message to Financial Transaction Manager for it to map the outbound structure to a physical file. The broker workflow and the subtype of the transmission definition determine which outbound mapper is called to build the physical transmission and route it to the appropriate channel (this is not the channel that is used by the outbound Gateway).
See Chapter 7, “Delivery of payments to receiving points” on page 179 for information about creating the artifacts necessary for proper transmission creation.
Users must be given access to Distribution and its functions. The following groups can be used to grant different permissions in the Control Center → Administration → Security → Groups:
•Distribution administrators
Contains access to all of the Distribution user interface functions. This includes access to the Properties tab for configuring the basic runtime parameters for the Distribution engine.
•Distribution supervisors
Contains permissions for managing the daily operations of Distribution. It includes all actions in the system, such as building transmissions or processing eligible transactions. By default, supervisors cannot see or manipulate the properties of Distribution.
•Distribution users
A read-only group that allows users to view the work processed by Distribution
The primary (and default) user ID for the Distribution user interface is created at installation time. The primary user ID, izladmin by default, is assigned to the Distribution Administrators group during installation. More details about which views and options are visible to every group are available in the IBM Knowledge Center → at:
To integrate Distribution in Payment Feature Services, communication with the Transaction Server must be set up. The Transaction Server can be configured, using its Scheduler.xml file, to send several types of messages to the Distribution engine.
The event types that are used by distribution are noted in the following list:
•PresentmentStateChange
•PresentmentColumnChange
•PresentmentGroupColumnChange
•PaymentExceptionChange
•EndOfDayCheck
•BusinessDayPurgeEvent
•BusinessDayStatusChange
•HoldoverBusinessDayEvent
•SendEndOfDayFilesEvent
5.7.1 PresentmentStateChange
The PresentmentStateChange event occurs when the state of an inbound batch changes. For example, when a batch finishes loading in the Transaction Server, the state of the batch changes to loaded and a PresentmentStateChange event occurs. The following message types can be configured for a presentment state change event:
•presStatesReached
Configure the event in the scheduler XML file so the class is called when the event occurs. The class name is:
paydir.ima.txsvr.event.appbridge.PresentmentReadyEventHandler
The PresentmentReadyEventHandler class creates the presStatesReached message to be sent to the Distribution engine. When the Distribution engine receives the presStatesReached message, it looks for all eligible transactions in the specified batch that are ready to be mapped to an outbound bundle. The msgType parameter defines the type of message to send, presStatesReached. The parmFileName parameter defines the properties necessary for sending a message to the Distribution engine. See the Distribution Parameter File for more information about using parameter files. Each presStates parameter defines the presentment states that must be met for the message to be sent. Example 5-8 shows a sample definition of a PresentmentStateChange event.
Example 5-8 Sample definition
<EVENT>
<NAME>Distribution - Batch</NAME>
<TYPE>PresentmentStateChange</TYPE>
<TYPE>PresentmentColumnChange</TYPE>
<TYPE>PresentmentGroupColumnChange</TYPE>
<EXEC>
com.ibm.paydir.ima.txsvr.event.appbridge.PresentmentReadyEventHandler
</EXEC>
<PARAMETER name="workType">Present</PARAMETER>
<PARAMETER name="msgType">presStatesReached</PARAMETER>
<PARAMETER name="presStates1">LOADED,AUTH_CHECKED</PARAMETER>
<PARAMETER name="presStates2">BALANCED</PARAMETER>
<PARAMETER name="group.condition">ACCEPTED</PARAMETER>
<PARAMETER name="condition">ACCEPTED</PARAMETER>
<PARAMETER name="pending">N</PARAMETER>
<PARAMETER name="presLevel">PROC</PARAMETER>
<PARAMETERREF>schedulerReferenceProperties</PARAMETERREF>
<PARAMETERREF>sendToDistribution</PARAMETERREF>
</EVENT>
•fileToFileCheck
Configure the event in the scheduler XML file so the class is called when the event occurs. The class name is:
com.ibm.paydir.ima.txsvr.event.appbridge.PresentmentGroupEventHandler
The PresentmentGroupEventHandler class creates the fileToFileCheck message to be sent to the Distribution engine. When the Distribution engine receives the fileToFileCheck message, it determines whether any outbound transmissions are configured for file to file delivery and associated with the corresponding inbound transmission. If so, distribution ensures that all of the eligible transactions from the inbound transmission are mapped. After all of the inbound transactions are mapped, distribution builds and releases the corresponding outbound transmissions that have transactions that were delivered in the inbound transmission.
The msgType parameter defines the type of message to send, fileToFileCheck. The parmFileName parameter defines the properties necessary for sending a message to the Distribution engine. A sample definition of a PresentmentGroupStateChange event for fileToFileCheck can be found in the SchedulerReference.xml file.
5.7.2 PaymentExceptionChange
A transaction exception change event is sent when a transaction in the FTM database is updated from being an exception to not being an exception. The exception column in the transaction table changes from 1 to 0. Configure the Transaction Server to send the Distribution engine a transactionReady message when a transaction is updated by configuring a PaymentExceptionChange event in the Scheduler.xml file.
Configure the event in the scheduler XML file so the class is called when the event occurs. The class name is:
com.ibm.paydir.ima.txsvr.event.appbridge.PaymentReadyEventHandler
A sample definition of a PaymentExceptionChange event can be found in the SchedulerReference.xml file.
The PaymentReadyEventHandler class creates the transactionReady message to be sent to the Distribution engine. When the Distribution engine receives a transactionReady message, it maps the transaction to an outbound bundle if the transaction is eligible. The msgType parameter should be set to transactionReady. The parmFileName parameter defines the properties necessary for sending a message to the Distribution engine. It is also possible to use the Distribution Parameter File. The minPresStates parameter defines the state that the transaction’s batch must be in before a message is sent to the Distribution engine. If a transaction is updated before its batch is balanced, a message is not sent. If the transaction is updated and its batch is balanced, a message is sent to Distribution.
5.7.3 EndOfDayCheck
Configure the Transaction Server to send the Distribution engine an end of day message when it is running end of day for a business day by configuring an EndOfDayCheck event in the Scheduler.xml file.
Configure the event in the scheduler XML file so the class is called when the event occurs. The class name is:
com.ibm.paydir.ima.txsvr.event.appbridge.EndOfDayCheckEventHandler
A sample definition of a EndOfDayCheck event can be found in SchedulerReference.xml.
The EndOfDayCheckEventHandler class creates the endOfDayCheck message that is sent to the Distribution engine. The msgType parameter must be set to endOfDayCheck. The parmFileName parameter defines the properties necessary for sending a message to the Distribution engine.
5.7.4 BusinessDayPurgeEvent
Configure the Transaction Server to send the Distribution engine a purge message when the Transaction Server is purging a business day by configuring an event with the BusinessDayPurgeEvent parameter in the Scheduler.xml file.
Configure the event in the scheduler XML file so that the class is called when the event occurs. The class name is:
com.ibm.paydir.ima.txsvr.event.appbridge.PurgeEventHandler
A sample definition of a BusinessDayPurgeEvent event can be found in the SchedulerReference.xml file.
The PurgeEventHandler class is responsible for building the purge business day message that is sent to the Distribution engine. The msgType parameter must be set to purgeBusinessDay. The parmFileName parameter defines the properties necessary for sending a message to the Distribution engine.
5.7.5 BusinessDayStatusChange
Configure the Transaction Server to send the Distribution engine a BDayActive message when activating a business day by using the BusinessDayStatusChange event in the Scheduler.xml file.
Configure the event in the scheduler XML file so the class is called when the event occurs. The class name is:
com.ibm.paydir.ima.txsvr.event.appbridge.BusinessDayStateEventHandler
A sample definition of a BusinessDayStatusChange event can be found in the SchedulerReference.xml file.
The BusinessDayStateEventHandler class creates the business day status change message sent to the Distribution engine when the business day status changes to one defined in the state parameter. The state parameter must be set to active. The message type parameter must be set to BDayActive. The parameter file name defines the properties required to send a message to the Distribution engine.
5.7.6 HoldoverBusinessDayEvent
Configure the Transaction Server to send the Distribution engine a BusinessDayHoldover message when initiating holdover for business day using the HoldoverBusinessDayEvent event in the Scheduler.xml file.
Configure the event in the scheduler XML file so the class is called when the event occurs. The class name is:
com.ibm.paydir.ima.txsvr.event.appbridge.HoldoverBusinessDayEventHandler
A sample definition of a HoldoverBusinessDayEvent event can be found in the SchedulerReference.xml file.
The HoldoverBusinessDayEventHandler class creates the holdover message sent to the Distribution engine when the business day holdover process is requested. The message type parameter must be set to BDayHoldoverEvent. The parameter file name defines the properties that are required to send a message to the Distribution engine.
5.7.7 SendEndOfDayFilesEvent
The user can request that any files scheduled for end of day delivery be sent by Distribution. This option is available on the business day management window in the Transaction Server.
Configure the Transaction Server to send the Distribution engine a send end of day files message when requested for the business day by using the send end of day files event in the Scheduler.xml file.
Configure the event in the scheduler XML file so the class is called when the event occurs. The class name is:
com.ibm.paydir.ima.txsvr.event.appbridge.SendEndOfDayFilesEventHandler
A sample definition of a SendEndOfDayFilesEvent event can be found in the SchedulerReference.xml file.
The send end of day files event handler class creates the send end of day message sent to the Distribution engine when the user requests the transmissions be sent. The message type parameter must be set to sendEODFiles. The parameter file name defines the properties that are required to send a message to the Distribution engine.
When Distribution receives this message, any transmissions that are scheduled for end of day delivery for that business day that have not been delivered are built and released.
Further information about these events can be found in the IBM Knowledge Center at:
5.8 Outbound billing
Outbound billing generates billing records for batches that are sent. As batches are processed by Distribution, the assigned endpoint is associated with a customer and outbound product code. When the transmission is sent by Gateway (outbound), the Transaction Server initiates an event that sends a message to Services Framework. This message tells Services Framework to run the outbound billing task for the processed batch.
Outbound billing determines whether the batch was already processed. If it was, it is not processed again. If the batch has not been billed, outbound billing accesses the outbound product associated with the endpoint and determines if billing is active for the product. If billing is active and the product has billing codes defined, outbound billing generates transmission and batch billing records. It also generates a summary transaction billing record for each transaction billing code in the batch. Multiple transaction billing records can be generated for a batch because each transaction in the batch is assigned a batch billing code.
Outbound billing determines whether the outbound product has any services defined. If it does and receiving customers are subscribed to the service, outbound billing generates transmission, batch, and transaction level billing records for the services to which the customers are subscribed. The type of outbound service affects how the transaction billing records are generated:
•Delivery (with a cutoff time specified):
All transactions are included in the transaction billing record if the delivery time of the batch is before the cutoff time
•Delivery (without a cutoff time specified):
Transactions in the batch are included in the batch billing record
When outbound billing processing completes, it sets the state of the batch to billed.
At the start of each new business day, outbound billing is called. At that time, it looks for all endpoints that subscribe to an outbound product that has a daily billing code. It generates a billing record for each subscribed endpoint with the outbound product found. This process is repeated for all subscription services in a product.
Outbound billing can be run manually. When it runs manually, it looks for all inbound transmissions that are not yet processed and submits a request to Services Framework to process them. For more information about running outbound billing manually, see the Services Framework User's Guide in the IBM Knowledge Center at:
Outbound billing does not participate when an inbound transmission is unloaded because the transactions are already transmitted before it is called. The operational staff need to manually adjust the billing records for transmitted transactions.
Outbound billing can participate in end of day processing. When outbound billing is called by Services Framework as part of an end of day query, it checks that outbound billing has been completed for batches whose state matches the prerequisite state defined in the task configuration, and whose associated product has billing enabled. If one or more batches have not been processed, outbound billing reports to Services Framework that it is not ready for end of day processing and lists the batch IDs that it has not processed. The operator can run outbound billing manually to process the missed batches.
To automate outbound billing processing as batches are sent from the system, configure the Transaction Server to alert the outbound billing task of specific events. Example 5-9 shows a typical configuration that uses the Transaction Server Scheduler.xml file to set up the event reporting. For more information, see the IBM Knowledge Center at:
Example 5-9 Typical configuration for even reporting
<EVENT>
<NAME>Outbound Billing</NAME>
<TYPE>OutPresentmentGroupState</TYPE>
<EXEC>
com.ibm.paydir.ima.txsvr.event.appbridge.OutPresentmentGroupStatesEventHandler
</EXEC>
<PARAMETER name="msgType">TaskInitiation</PARAMETER>
<PARAMETER name="presStates1">SENT</PARAMETER>
<PARAMETER name="jmsUserId">pduser</PARAMETER>
<PARAMETER name="jmsPassword">pduser10</PARAMETER>
<PARAMETERREF>schedulerReferenceProperties</PARAMETERREF>
<PARAMETERREF>sendToBillingOutbound</PARAMETERREF>
</EVENT>
The event configuration is given the name Outbound Billing. Any unique event name can be used. The event is started by specific event types, such as Outbound presentment group state.
The executed event handler relays the events to the target queue by using a Messaging API message:
com.ibm.paydir.ima.txsvr.event.appbridge.PresentmentGroupStatesEventHandler
The remaining parameters are used to send a message to a specified message queue on which Services Framework is listening. For more information about the parameters, see the IBM Knowledge Center at:
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.