Introduction
This chapter provides an overview of Financial Transaction Manager for ACH and explains the key components of the product. It also provides a feature comparison between Financial Transaction Manager for ACH, Corporate Payment Services, and Check for a quick reference.
The chapter starts with an overview of Financial Transaction Manager for ACH, then explains the technical components of the product including the operational user interface. It provides an overview of end-to-end processing of a payments file in Financial Transaction Manager for ACH. It describes how to import and export system configuration using the data setup utility (DSU) supplied with the product.
This chapter includes the following sections:
1.1 Overview of Financial Transaction Manager for ACH
Automated Clearing House (ACH) payment volume is increasing every year. NACHA, the electronic payments organization, estimates that ACH payments exceeded 21 billion in 2012. There are more than 10,000 financial institutions that support NACHA that generate these billions of transactions every year. This transactions volume has dramatically changed the requirements of ACH processing. As result, financial institutions are re-evaluating their current payment platforms.
Virtually all financial institutions have multiple systems to process payment, trade, and securities messages. These systems have evolved over years or even decades, and were implemented to be efficient at processing the needs of a particular department, function, or customer set. The evolution at different times and paces created duplicate functionality across the systems. This duplication hampers the client relationship due to the difference in the processes across business functions. Additionally, these monolithic applications and the complex integration between them results in higher operating cost than the revenue that they generate. The situation creates strong pressure to reduce costs because the increasing transactional volume might be unable to compensate for the revenue/cost differential.
With the dawn of new consumer channels such as online, mobile, and social, customers are demanding improved information access to their payments. This situation creates new requirements in the payments infrastructure that never existed before such as near real-time payment status visibility, automated exception handling, and same-day processing. Along with higher customer expectations, financial firms are being tasked with reducing costs and offering new services to create more revenue. At the same time, they must reduce financial risk and ensure compliance with regulatory standards. With multiple types of payments flowing through multiple channels, a single view of all types of customer payments can help them address these issues.
The IT operations in the ACH processing are facing significant challenges too. They need to address the following key questions, among others:
•How do I gain value from existing assets that are part of complex and unconnected transactional systems?
•How do I meet the business requirements in the quickest manner with aging systems built on a legacy platform that is costly to maintain and upgrade?
•How do I build the support for new transaction types on these legacy systems?
•How do I manage skill attrition and the retiring of staff that support these systems?
IBM Financial Transaction Manager for ACH Services provides pre-built support for processing all ACH transactions that flow through your system, including ingestion, validation, transaction management, and distribution. A robust rules-based environment handles payment routing and exception management, and an automated import and export facility handles ACH processing rules. Other key functions include administration, process management, data warehousing, and reporting and extracts.
Implementing Financial Transaction Manager for ACH Services has the following benefits:
•Is agile in reaction to change
•Provides visibility of payments processes at design time and run time
•Integrates existing service components that are built, bought, or both
•Facilitates renovations by wiring together reusable service components
•Reduces the cost and impact of change
•Reduces the cost of testing additional applications with external networks
•Enhances liquidity management monitoring and control
•Reduces cost by enabling payment efficiencies and reducing system duplication
•Improves customer satisfaction with faster time to market
1.2 High-level architecture and key components
Financial Transaction Manager for ACH consists of multiple functional and technical components that are pre-integrated to form the complete solution. Figure 1-1 shows key components of Financial Transaction Manager for ACH.
Figure 1-1 High-level architecture overview of Financial Transaction Manager for ACH
The inbound gateway receives a file from a sending point and accepts it for processing. The gateway server then parses the file and performs high-level validations. It starts the business rules process server for additional validation and enrichment that might be needed. It then notifies the transaction server to continue processing.
The transaction server orchestrates a series of invocations to various auxiliary and remediation components that include Transaction Correction and Reconciliation (TCR), Risk, and NOC engine for processing. After the processing is complete, it notifies the distribution engine that the transactions are ready to be sent to the receiving point. The distribution engine picks up these transactions and creates outbound batches based on rules configured in the system. It then translates these outbound batches into outbound transmissions, which are physical files to be sent out. It notifies the outbound gateway server to send these files to the appropriate receiving points.
Outbound gateway server sends these files to receiving points and optionally sends acknowledgment back to the distribution engine. The following sections provide an overview of these components and capabilities they offer.
1.2.1 Gateway server
The gateway server is responsible for processing inbound transmission files for the transaction server. It is also responsible for delivering the transmission files that are generated by the distribution component to the receiving points.
Inbound processing
The gateway server provides an inbound interface for Financial Transaction Manager for ACH to process inbound files. The gateway listens for any inbound files in a predefined and configurable directory on the file system. When the file arrives in the directory, the gateway server performs the following tasks:
•Consumes the inbound transmission and assigns the clearing date (also known as business day) and product to the file processing. The gateway server uses business rules workflow to determine the business day for processing this file along with the product to be used. For more information about configuring the workflow, see Chapter 4, “Product and clearing date selection workflow” on page 75.
•Performs high-level validations driven by the configuration data. For more validation, it uses the business rules workflow as defined in the configuration. For more information about configuring the validation rules, see Chapter 3, “Validating, enriching, and routing of payments” on page 53.
•If configured, performs the Control Total Verification for the inbound transmission.
•Matches each return transaction to the corresponding forward transaction.
•If configured, and depending on transaction type, starts the Notification of Change (NOC) and Death Notification Entry (DNE) components.
•Saves the resulting transactions to the database and sends a message to the transaction server for processing further.
Outbound processing
The gateway server on the outbound side provides distribution capabilities to send the files to receiving points. On the outbound side, it performs the following tasks:
•Sends files to receiving points using File copy, FTP, email, User Exit, FTM Workflow, and Connect:Direct®.
•Sends a group of files consisting of one or more actual payments file, route file, and EOF file.
•If configured, sends a notification back to the distribution indicating that the transmission has been sent.
See Chapter 7, “Delivery of payments to receiving points” on page 179 for details of outbound gateway server configuration.
 
Tip: See the Financial Transaction Manager for ACH information center at Financial Transaction Manager for Multiplatforms 3.0.0 → Payment Feature Services → Gateway Server User's Guide for a detailed user guide.
1.2.2 Gateway engine
The gateway engine revalidates and might add additional information to transactions that were consumed using a business date that is in the future. Even though some of these transactions are assigned business dates that are days or weeks into the future, the transactions are validated when they are consumed. When the business day is activated, the transactions that were previously consumed might need to be revalidated. For example, if the business day is being activated at a different time of day than when it was originally consumed, the endpoint that was previously assigned by business rules might need to be changed. The exchange (FX) rates used to calculate the system and outbound amounts might have also changed since the transaction was originally consumed.
When an open business day is activated, an activated message is sent to the gateway engine. When the gateway engine receives the message, it processes all of the batches for the business day that are in the captured but not loaded state. If the gateway is configured to use business rules, and a business rules workflow was used during ingestion, the gateway calls business rules with the same workflow to revalidate each transaction in the batch. Because an updated transaction is saved to the database, the current exchange (FX) rates are applied to the system and outbound currency.
After the gateway engine processes all of the transactions for a batch, the batch is set to the loaded state. Any events in the transaction server scheduler that require the loaded state start further processing for the batch.
If the gateway engine encounters a configuration problem while processing the activated message, the error can be corrected and the request resent to the gateway engine. After the error has been corrected, re-send the request by closing the business day and then reactivating it. Any batch that is not in the loaded state is processed by the activated message.
 
Tip: For more information about gateway engine, see the Financial Transaction Manager for ACH information center at Financial Transaction Manager for Multiplatforms 3.0.0 → Payment Feature Services → Gateway Server User's Guide → Gateway Engine.
1.2.3 Business rules process server
The business rules process server allows configuration and execution of advanced business rules for payments processing. These rules determine business day and product identification, advanced validation rules, routing rules, and processing rules.
Business rules are configured as workflows that consist of a series of nodes and tasks that are represented as XML documents. You can create these by using the Control Center or the DSU. Figure 1-2 depicts the relationship between these nodes and tasks.
Figure 1-2 Structure of workflow components
The relationship between the nodes and tasks of the workflow components has these characteristics:
•A workflow consists of a series of nodes that are connected to each using connections.
•It also consists of response nodes that determine what response is returned to the caller.
•A node consists of a series of tasks connected by using connections.
•It consists of assignments for initializing certain variables for task execution.
After the workflows are created, business rules distribution manager compiles them into tables and rows to be distributed to all the business rules server instances in the system.
When an operator activates a release that consists of one or more business rule workflows, the Control Center notifies the distribution manager component. The distribution manager extracts the rules data from the database by using database views and compiles the extracted data. These exacted rules are validated for correctness and any errors are reported back to the operator through the Control Center. If the validation succeeds, it then notifies all the instances of business rules process server of new rules using the IBM WebSphere® MQ publish-subscribe mechanism.
The business rules process server uses these pre-compiled rules for execution based on the rules configuration. These pre-compiled rules are cached in memory for optimal performance.
1.2.4 Notification of Change (NOC) and Death Notification Entry (DNE)
NOC and DNE are used by the Receiving Depository Financial Institution (RDFI) and Originating Depository Financial Institution (ODFI). On the RDFI side, the registered partner’s details might change over time. Thus, it is important to inform the ODFI about this change. The changed details might include the following terms:
•Account number
•Routing number
•Account name
The NOC is a mechanism to manage these changed details between RDFI and ODFI. The component also processes DNE. DNE indicates that the recipient of a government benefit payment has died. These entries are generated only by government agencies. Thus, the product does not allow creation of NOC entries.
NOC on the ODFI side
The ODFI is responsible for following processing related to NOC.
Receiving NOC records
An RDFI sends an NOC batch to the ODFI indicating various changed records for their partners. Financial Transaction Manager for ACH validates each transaction in this batch. If the validation passes, the NOC records are stored in the Financial Transaction Manager for ACH database. If validation fails, the product generates NOC refusal to RDFI.
NOC on the RDFI side
The RDFI is responsible for generating the NOC records. The NOC component of the product provides a user interface to generate transactions to be sent to the ODFI through the ACH provider.
The component is also responsible for accepting NOC refusals from ODFI. These refusals are displayed in the Control Center for operator to action. After it is corrected, the product allows resending these NOC transactions to ODFI.
DNE on the RDFI side
When DNE batches are received, they are sent to the Notification of Change and Death Notification Entry components for processing. The data in a DNE transaction affects the processing of government benefit payment transactions received by the RDFI on behalf of its partners. When an RDFI receives a DNE, it can use the DNE data to start an investigation and initiate stop payment activity if necessary.
Financial Transaction Manager for ACH provides a page in the Control Center that allows the user to view and add comments to DNE records. However, as described earlier, there is no capability to add or change these records.
1.2.5 Transaction server
The transaction server is the orchestration engine of Financial Transaction Manager for ACH. It is responsible for processing these transactions according to the defined workflow. Financial Transaction Manager for ACH provides an XML-based workflow engine to define various steps in the processing. As a transaction moves through various states, the transaction server raises events to start additional steps in the transactions. These steps can include sending the transactions to risk processing, billing, settlement, distribution, and notifications. Chapter 5, “Remediation and auxiliary processing workflow” on page 83 describes how these workflows are created and managed in Financial Transaction Manager for ACH.
1.2.6 Risk management
Risk Management provides real-time financial exposure limit management. It monitors incoming batches and transactions to ensure that they do not exceed specified limits for an originating partner. There are different types of risk management capabilities provided by the product depending on the role that a financial institution is playing (ODFI or RDFI). These overall capabilities are offered by the risk management component:
•Configuration of risk management parameters during partner onboarding
•Dynamic, real-time configuration
•Runtime processing of incoming work
•User interface to review, override, and cancel batches and transactions that failed risk review
ODFI side
The risk management on the ODFI side consists of reversible, stateful, and re-entrant workflow steps. The engine implements multiple checks and monitors to ensure limit compliance. As the batch or transaction moves through these steps, the monitors keep incrementing the counters for processed value of transaction. If a batch or a transaction is rejected by risk management, these steps are run in reverse order to compensate for the changes made to the counters and attributes. This process reverses the effect of risk management. There are six checks in risk management on the ODFI side:
•Batch limit check
•Prefunded batch check
•Batch monitor check
•Transaction limit check
•Prefunded account check
•Transaction monitor check
RDFI side
The risk management on the RDFI side provides advanced payment authorization capabilities to manage inbound batches and transactions. Each payment passes through a series of checks to ensure compliance. These checks are as follows:
•Payment authorization
•Positive Pay
•Stop Payment
•Payment Filtering
See Chapter 5, “Remediation and auxiliary processing workflow” on page 83 to understand these ODFI and RDFI-related steps in detail.
1.2.7 Distribution
The distribution component creates outbound transmissions to be sent out and sends them over to the outbound gateway server for processing. The transaction server triggers the distribution engine based on the steps that are configured in the workflow. The distribution engine picks up all the eligible transactions in the database for processing. Eligible transactions are those that pass validation and are not waiting for any remediation processing.
After the eligible transactions are picked up, the component groups them together based on definitions of banks, partners, endpoints, transmission definitions, and building options to create outbound batches and transmissions. These transmissions are then scheduled for transmission to the gateway server based on transmission delivery scheduling configuration.
The distribution component also manages these transmissions at run time such as overriding scheduled transmission delivery to deliver transmissions that are not automatically scheduled.
See Chapter 7, “Delivery of payments to receiving points” on page 179 for configuration details of the distribution component.
1.2.8 Settlement
Settlement tracks and maintains the real-time financial state of all electronic transactions being imported and completed by the payment system within the Financial Transaction Manager for ACH infrastructure. Settlement tracks inbound transaction totals and outbound transaction totals for work that comes into and goes out of Financial Transaction Manager for ACH, including:
•Incoming batches from external originators and bank branches that come into Transaction Server and adjustments to those batches.
•Outgoing on-us transactions from Transaction Server or 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).
The settlement options in the Control Center provide this data:
•A summary total for inbound accepted batches and outbound work
•Totals for inbound batches by individual originators
•Totals for outbound work that were sent or are waiting to be sent, for transit transactions by endpoint
•Totals for outbound work that were sent or are waiting to be sent, for on-us work by endpoint
•Pending totals for work that are expected to be sent, but have not yet been accounted for in the outbound transit or on-us work
1.2.9 Services framework
Service framework provides a capability to run specific tasks in Financial Transaction Manager for ACH. It supports both business tasks, such as activating a business day, creating billing extracts, and importing FX rates, and technical tasks such as log purging, email notifications, alert notifications, and activity purges. However, the tasks can be created for any task that are needed in the payment processing.
The services framework consists of these components:
•Engine
•User interface
•Software development kit (SDK)
The tasks are created as Java programs for which Financial Transaction Manager for ACH provides a framework and SDK. After they are created, these tasks can be added to the system configuration by using the Control Center.
Financial Transaction Manager for ACH provides a number of predefined tasks across various components described earlier in this chapter that can be configured according to requirements.
 
Note: Services Framework SDK is provided as Java libraries.
1.2.10 Web services
Web services enables a financial institution to integrate various aspects of Financial Transaction Manager for ACH into their applications and interfaces, such as the following:
•Client facing user interface
•Internal user interface
•Distributed applications
•Legacy applications
For example, financial institutions can provide the status of the work submitted and can submit control totals through an existing portal that they already use. This allows a seamless end customer experience.
 
Note: Web services are provided only to integrate limited features of the product into the financial institution’s existing system. The product does not provide a web service for every function that it offers.
Additionally, the web services component provides a sample web services client that provides a web-based interface to start any web service that is provided by Financial Transaction Manager for ACH. The component provides the following services:
•List Inbound Transmissions
•List Inbound Batches
•List Inbound Transactions
•List Validation Results
•List Outbound Transmissions
•List Transmission Types
•List Batch Types
•List Payment Record Types
•List Message Standards
•List Message Types
•List Inbound Products
•List Business Days
•List Physical Transmissions
•TCR Lock
•TCR List Active Work
•TCR List Transactions
•TCR Discard Active Work
•TCR Complete Active Work
•TCR Approve Active Work
•TCR Unlock Active Work
•TCR Delete Transactions
•TCR Validate Transaction
•TCR Transaction Details
•TCR Update Transaction
•TCR Unlock
•TCR Get Pending Updates For Transaction
•TCR Undelete Transactions
•TCR Insert Transaction
•TCR Undo Transactions
•TCR Reload Active Work
•User Entitlements
•Add Control Total
•Decision Pending Batches
1.2.11 Component interaction
Although the gateway server interacts with the business rules process server by using socket communication and with the gateway engine using Internet Inter-ORB Protocol (IIOP), most of the communications between the components use IBM WebSphere MQ. Figure 1-3 depicts the major component interaction that uses WebSphere MQ queues. The product provides detailed instructions for creating the WebSphere MQ configuration. See the Financial Transaction Manager for ACH information center section Financial Transaction Manager for Multiplatforms 3.0.0 → Payment Feature Services → Installation → Setting up WebSphere MQ for Payment Feature Services for details.
Figure 1-3 Component interaction
1.3 End-to-end processing overview
This section provides a typical workflow of a payments file from ingestion to distribution inside Financial Transaction Manager for ACH and various components that it passes through. It does not describe how to add the processing configuration for this process. The section also introduces various product-specific terminologies that are used in remainder of the book. Additionally, it provides a list of critical tasks that need to be completed from the product configuration perspective to successfully process a payments file. Figure 1-4 depicts the possible processing path of an inbound NACHA file from a sending point.
Figure 1-4 End-to-end processing overview
 
Note: Financial Transaction Manager for ACH supports many other complex scenarios that are not depicted in this section.
1.3.1 Ingestion
The sending point collects all the payments from all the originators and creates a file with multiple batches to be sent to the ODFI. The batches in the file are in NACHA format. The file is transferred to Financial Transaction Manager for ACH landing zone along with an EOF file that designates that the file is ready to be picked up by the gateway server.
The configuration might specify validating the file against control total information that is sent by the sending point. The control total ensures that the transmission sent by sending point is not altered during the transit.
Financial Transaction Manager for ACH verifies the control total against the file received. If the validation fails, the file is rejected. If it succeeds, the processing performs high-level validations on the file to ensure that it complies with NACHA standards.
The gateway then starts the business rules component to assign a business day/processing day to the file and the product to be used for processing the file. This business rules server also performs extra validation and enrichment of the message based on configuration. See Chapter 4, “Product and clearing date selection workflow” on page 75 for details of configuring this flow.
The gateway server then creates inbound batches and transactions based on the information in the transmission and sends a control message to the transaction server for processing these transactions.
If the processing day for these transactions is current and active, the processing continues. If the business day is not current or not active, the transactions and batches are stored in the warehouse to be processed later.
When the business day is activated, either through the Control Center or through a scheduler, the gateway engine is notified. The gateway engine checks the warehouse for the transactions that are marked to be processed for the current business day. These transactions are revalidated and then sent to the transaction server for processing.
Before a file can be imported by Financial Transaction Manager for ACH, the following activities must be completed from the product configuration perspective:
•Create product selection workflow: See Chapter 4, “Product and clearing date selection workflow” on page 75 for details.
•Configure validation and enrichment rules: See Chapter 3, “Validating, enriching, and routing of payments” on page 53 for details.
•Onboard partner(s): See Chapter 6, “Onboarding a partner” on page 111 for details.
1.3.2 Remediation and auxiliary processing
The transaction server is responsible for orchestrating various remediation and auxiliary processing steps. The transaction server uses a scheduler xml configuration, which describes various steps and orchestration rules for transaction processing. In the workflow shown in Figure 1-4 on page 12, there are four steps that are considered for transaction processing. However, these steps along with their sequence can change based on the financial institution’s requirements. The four steps are as follows:
•Step 1
The transactions can be configured to be authorized by the sending point. In such cases, the transactions are put into the suspended state until authorized. The authorization can either be provided by using the Control Center or by using web service invocation.
•Step 2
After being authorized, the transactions are sent to the risk management component for risk review. If the risk review fails, the transactions are put in the suspended state until an operator takes an action. Additionally, risk monitors can be configured to reject the batch in case of risk review failure.
•Step 3
Additionally, if configured, the gateway server calls the Notification of Change and Death Notification Entry components to check whether any accounts in any transactions need to be updated based on records in these components.
•Step 4
The transactions are then sent to the distribution engine for delivery to receiving points.
Remediation and auxiliary processing requires the following configuration to be done.
•Configure financial exposure risk monitors: See Chapter 5, “Remediation and auxiliary processing workflow” on page 83 for details.
1.3.3 Distribution to receiving point
The distribution engine picks up all the eligible transactions in the database. Eligible transactions are those that have passed validation and are not waiting for remediation operations.
Based on receiving destination (endpoint) configuration, distribution engine creates outbound batches of transactions. Outbound batches consist of groups of transaction that are put into an outbound transmission file.
 
Note: All of the outbound batches in an outbound transmission file must be going to the same receiving endpoint
The outbound batch can contain all the transactions from the inbound batch that have the same processing date. For example, consider an inbound processing batch that consists of five debit transactions and four credit transactions that need to be sent to the ACH operator to be processed on the 15th of September that need to be sent to the same endpoint. According to ACH rules, debit transactions are sent one business day in advance of the actual settlement date (September 14) and credit transactions will be sent two days in advance of actual settlement dates (September 13). Thus, the outbound batch on September 13 consists of only four credit transactions from this batch and the outbound batch on September 14 consists of five debit transactions from this batch. Thus, one inbound batch is split into two outbound batches to ensure compliance with ACH rules.
After the outbound batches are created, the distribution engine uses endpoint information to schedule these batches automatically (either at specific time or at end of day) or leave them in unscheduled status to be processed manually by an operator.
When the outbound batch is ready to be sent to the receiving point, the distribution engine creates the physical transmission file along with EOF file. It then sends these files to the outbound gateway server to be sent to the receiving point based on the configuration.
For distribution of file to receiving points, Financial Transaction Manager for ACH requires the following configuration to be completed:
•Create outbound channels
•Create transmission definition
•Configure endpoints
•Schedule transmission delivery
1.4 Overview of the operational user interface
The operational user interface is used to configure, monitor, and control the operation of payments flowing through the system. The operational user interface is secured with authorization framework in Financial Transaction Manager for ACH that provides different menu options to different groups of people based on their role in payment lifecycle. This section describes various operational user interface menus based on the logical roles (groups) that the person needs to perform. Each implementation of Financial Transaction Manager for ACH should create these roles with the appropriate permissions.
 
Note: If a user does not have permissions to either a user interface window or action on that window, then that window or action will not be visible to the user.
1.4.1 Control Center
Control Center is the portal for configuring, monitoring, and managing payment transactions that are processed in Financial Transaction Manager for ACH. Figure 1-5 shows the main window of the Control Center. The key sections of the main window are numbered and described below.
Figure 1-5 Control Center overview
1. Menu bar
The menu bar provides various role-based options. There are several different menu options:
 – Administration
 – Configuration
 – System Management
 – Origination & Receipt
 – Processing & Remediation
 – Distribution
 – Financial Management
This section describes these menu options in the context of a specific role. Although this book provides typical user-role-based information of Control Center, users might have access or a role to play with multiple menu options (as required by the customer).
 
Note: This chapter does not describe each menu option in detail. It does provide pointers to the information center section for the appropriate menu option.
2. Available applications
This section of the window provides a quick overview of the components that are installed in the system and which the user has access to.
3. Timezone
The timezone section provides the current configured time zone for the current logged in user. Control Center uses this to format time values for display. Other users see those values formatted in their own timezones.
1.4.2 Technical support team
The technical support team works mainly with the Administration menu of the Control Center as shown in Figure 1-6.
Figure 1-6 Administration menu
The Administration menu consists of menu options that allow technical support team and system administrators to manage system performance and security, configure properties of various components, and manage custom attributes. See the Financial Transaction Manager for ACH information center at Financial Transaction Manager for Multiplatforms 3.0.0 → Payment Feature Services → Control Center User's Guide → Control Center User Interface for more details about each menu option.
1.4.3 Business analyst
The business analysts are responsible for functional configuration of the system that includes configuring products, services, onboarding partners, transmission, and business rules. In the Control Center, the business analysts mainly work with the Configuration menu options as shown in Figure 1-7.
Figure 1-7 Configuration menu
With the options in the configuration menu, the business analysts are able to configure the properties of the inbound and outbound transmission, and various validation and business rules. Additionally, the business analysts can onboard a partner, and configure settlement monitors and various services tasks using the services framework.
1.4.4 Operations team
The operations team is responsible for managing the day to day operations of payment processing. Financial Transaction Manager for ACH provides three different menus for the operations team to work with. Figure 1-8 shows these menu options.
Figure 1-8 Menu options for business analyst
The menu options are as follows:
•System Management
The System Management menu is primarily for operations supervisor to perform tasks such as managing business days, managing various system alerts and notifications, and viewing notification of change and death notification records. The menu option also allows the supervisor to run tasks that are created using the services framework.
•Origination & Receipt
This menu option allows the operations team to manage the inbound physical transmissions, control totals, and transactions in a transmission. It also allows working with transmissions to override control total verification.
•Distribution
This menu option allows the operations team to manage outbound transmissions to perform tasks, such as scheduling transmissions, managing schedules of transmission, and overriding transmission of files if required. It allows remapping endpoints in case of operational issues without affecting the master configuration.
1.4.5 Exception management team
The Control Center allows the exception management team to perform remedial operations on the processed payments from the financial risk perspective. These actions include monitoring the task activity and monitoring exposure limits. The Control Center provides Processing & Remediation menu as shown in Figure 1-9.
Figure 1-9 Processing & Remediation menu
1.4.6 Finance team
Although the transactions flow through the system, Financial Transaction Manager for ACH monitors the position of each partner against the transaction and provides a consolidated view to the finance team to determine the intraday position of the financial institution and of a partner. The Control Center provides the Financial Management menu option to perform these tasks shown in the Figure 1-10.
Figure 1-10 Financial Management menu
1.5 Importing and exporting system configuration
Although the Control Center allows configuration of the entire system, Financial Transaction Manager for ACH provides a DSU to manage the configuration data within Financial Transaction Manager for ACH. The DSU minimizes the amount of time that is required to initialize and configure a new installation of the Financial Transaction Manager for ACH database. The DSU allows the user to consolidate the configuration data into spreadsheets instead of having to navigate through multiple user interface windows to configure manually. The DSU enables the user to do the following activities:
•Initialize and configure a new installation of the Financial Transaction Manager for ACH.
•Migrate configuration data between instances of Financial Transaction Manager for ACH, such as from quality assurance environment to production environment.
•Remove configuration data from the Financial Transaction Manager for ACH database that is no longer needed.
•Validate configuration data before loading into the Financial Transaction Manager for ACH database to ensure data consistency.
DSU has three key components that are described further in this section:
•Microsoft Excel workbooks
•Property files
•Command line tools
1.5.1 Microsoft Excel workbooks
The configuration data for Financial Transaction Manager for ACH is captured in a set of three Microsoft Excel workbooks.
Configuration Data workbook
This workbook contains the actual configuration data that needs to be imported or the data that is exported from Financial Transaction Manager for ACH. Each worksheet in this workbook corresponds to exactly one table in FTM configuration. The worksheet names do not need to be actual table names. However, they need to be unique. These names are mapped to actual table names in the cross referencing workbook. Each worksheet consists of number of columns corresponding to database columns. However, these column names do not need to be actual column names in the database. The mapping between column names in this worksheet and actual column name is maintained the map workbook that is described in the following section.
 
Tip: The configuration workbook file names usually end with the word Configuration. Example name of workbook is SampleBusinessRulesBaseConfiguration.xls
Map workbook
This workbook maps the user friendly column names in configuration data workbook to actual table column names in the database. For each sheet in the configuration data worksheet, there must be a worksheet within the map workbook. It is a preferred practice to keep worksheet names the same in both the workbooks to avoid confusion. In the samples provided with Financial Transaction Manager for ACH, note that some of the column names are shaded with a color. These shaded columns indicate which columns are part of the primary key for that table.
 
Tip: The map workbook file names usually end with the word Map. An example name for a workbook is BusinessRulesBaseMap.xls
Cross Reference workbook
This workbook governs which worksheets in the map and configuration data workbooks are used during the DSU execution. It also maps the user friendly table name (worksheet names) to the actual table names in the database.
The workbook consists of a four worksheets that correspond to each action of the DSU.
The import worksheet has six columns:
•Import sheet name
Name of the worksheet from the configuration data worksheet that needs to be acted on.
•Import
Flag to indicate whether this sheet should be imported into Financial Transaction Manager for ACH or not.
•Mode
Indicates what to do with the existing data. Either insert or update the data, or drop the existing data and insert new data.
•Map sheet name
Name of the worksheet from the map worksheet corresponding to this configuration worksheet.
•Database Table Name
Actual name of the database table from Financial Transaction Manager for ACH database.
•Update Key
The comma-separated list of column names that are used as the primary key to update the data in this database.
Figure 1-11 shows a sample Import worksheet.
Figure 1-11 Import worksheet example
The export worksheet has five columns:
•Export sheet name
Name of the sheet to create for exporting the data for this table
•Export
Flag to indicate whether to include this table in the export
•Map sheet name
Name of the sheet to create in the map worksheet
•Valid Release
Indicates the release number to be used for the exported data
•Query SQL
The actual query to run on the Financial Transaction Manager for ACH database to export the data.
Figure 1-12 shows a sample export worksheet.
Figure 1-12 Export worksheet example
The delete worksheet has two columns
•Delete
Indicates whether data from this table should be deleted.
•Database table name
The table name from the Financial Transaction Manager for ACH database for data deletion.
Figure 1-13 shows a sample delete worksheet
Figure 1-13 Delete worksheet example
The validate worksheet has three columns:
•Validate sheet name
Name of the sheet from the configuration data workbook to validate.
•Validate
Flag to indicate whether to validate this table or not.
•Map sheet name
Name of the sheet to validate in the map worksheet.
Figure 1-14 shows a sample validate worksheet.
Figure 1-14 Validate sheet example
 
Tip: The cross-reference workbook file names usually end with the word XREF. An example name of a workbook is BusinessRulesBaseXREF.xls.
Financial Transaction Manager for ACH is distributed with a sample set of configuration data workbooks. This sample configuration data might be applicable to all financial institutions. It is the responsibility of the financial institution to ensure that the configuration data in the sample configuration data workbooks meets their requirements.
 
Tip: Additional information about the DSU is available in the IBM Knowledge Center at Financial Transaction Manager for Multiplatforms 3.0.0 → Payment Feature Services → Installation → Data Setup Utility.
1.5.2 Property files
DSU properties files are used to specify the workbooks used for each DSU operation. The properties files also contains general information that the DSU needs to run. The most important of these keys are as follows:
•Path to three workbook file names as described in 1.5.1, “Microsoft Excel workbooks” on page 20.
•Environment configuration values and logging properties.
1.5.3 Command line tool
DSU is a command line tool. Financial Transaction Manager for ACH provides these tools for all the supported platforms. This command line tool provides a number of operations controlled by the parameters passed to the tool. The DSU command syntax looks similar to Example 1-1.
Example 1-1 DSU command syntax
For 32bit systems: DSU operation propertiesfile
For 64bit systems: DSU64 operation propertiesfile
The operation parameters have these possible values:
•import: Imports data to the database
•export: Exports data from the database
•delete: Deletes data from the database
•validate: Validates data before importing to the database
The propertiesfile parameter specified the location of the property files, which describes the various spreadsheets that are involved in this action. Example 1-2 shows sample DSU commands.
Example 1-2 DSU sample commands
DSU import BaseImport.properties
DSU export BaseExport.properties
 
1.6 Feature comparison of Financial Transaction Manager between ACH, Check Services, and Corporate Payment Services
Financial Transaction Manager for ACH is part of the Financial Transaction Manager family that consists of two extra key products and more. These two additional key products are Financial Transaction Manager for Corporate Payment Services and Financial Transaction Manager for Check Services. These products are part of the Financial Transaction Manager subfamily called payment feature services. They share a set of common components. Refer to the information center at Financial Transaction Manager for Multiplatforms 3.0.0 → Payment Feature Services for details of these common components. This section compares Financial Transaction Manager for ACH features with various features offered by these products.
1.6.1 Financial Transaction Manager for Corporate Payment Services
Financial Transaction Manager for Corporate Payment Services is designed to work with corporate payable and receivables. It provides payment services for the following entities:
•Corporate clients
•Internal bank applications
•Work received from other financial institutions
Financial Transaction Manager for ACH provides payment services to work with partner and ACH operators to process NACHA files.
Financial Transaction Manager for Corporate Payment Services provides a reference flow to work with Electronic Data Interchange (EDI) files and Financial Transaction Manager for ACH natively supports NACHA files.
Financial Transaction Manager for ACH uses gateway server for ingestion, validation, and enrichment. Financial Transaction Manager for Corporate Payment Services uses gateway server for business day assignment, product, and data enrichment.
Financial Transaction Manager for Corporate Payment Services relies heavily on the Financial Transaction Manager Base product for ingestion and extraction along with processing. Financial Transaction Manager for ACH uses the FTM base product only for control total verification and custom extracts.
Refer to the information center at Financial Transaction Manager for Multiplatforms 3.0.0 → Financial Transaction Manager for Corporate Payment Services for more details about Financial Transaction Manager for Corporate Payment Services.
1.6.2 Financial Transaction Manager for Check
Financial Transaction Manager for Check Services is designed mainly to work with check processing part of the payments. It provides the following services:
•The ability to repair payments
•Quality control for incoming check images
•Capture and storage management for incoming check images
Most of the components are common between Financial Transaction Manager for ACH and Financial Transaction Manager for Check Services, with a few differences:
•Financial Transaction Manager for Check Services is designed to work with X.9 format, whereas Financial Transaction Manager for ACH is designed for NACHA format.
•Financial Transaction Manager for Check Services does not have the Notification of Change management component that is provided with Financial Transaction Manager for ACH.
•Financial Transaction Manager for Check Services has additional components, such as payment repair and image-processing components that are included in Financial Transaction Manager for ACH. Click Financial Transaction Manager for Multiplatforms 3.0.0 → Financial Transaction Manager for Check Services for more information about the components that are provided with Financial Transaction Manager for Check Services only.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset