Business Configuration Guide Sap Liquidity Management For

Transcript

Business Configuration Guide SAP Liquidity Management for Banking 6.2 (LMS 6.2) LAST REVISED: Jun, 2017 Copyright © 2005-2017 SAP SE All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP SE and its affiliated companies (“SAP Group”) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other countries. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices. Disclaimer Please see http://www.sap.com/corporate-en/legal/copyright/index.epx for disclaimer information and notices. Documentation in the SAP Service Marketplace You can find this document at the following address: http://service.sap.com/ Table of Contents About This Document ................................................................................................. vi 1. Purpose ......................................................................................................... vi 2. CMM Module ................................................................................................ vi 1. Performing High-Level Configuration Tasks ................................................................. 1 1.1. Defining RAG Rules ...................................................................................... 1 1.2. Configuring Time Zones ................................................................................. 5 2. Configuring the Cash Flow Manager Module ................................................................ 6 2.1. CFM Configuration - Cash Transaction Matching Rules ....................................... 6 2.1.1. Rule Definition Information .................................................................. 7 2.1.1.1. Filtering Rules ......................................................................... 7 2.1.1.2. Selection Rules ........................................................................ 7 2.1.1.3. Matching Rules ........................................................................ 8 2.1.2. Constants .......................................................................................... 9 2.1.3. Operators and Tolerances ..................................................................... 9 2.2. CFM Configuration - Balance Transfers .......................................................... 10 2.2.1. Balance Transfers - Scheduled Balance Transfer Configuration ................. 10 2.2.2. Balance Transfers - Adapter Configuration (adpt_baltran) ........................ 11 2.2.2.1. Configuring the Poll Period ...................................................... 13 2.2.2.2. Maintaining Scheduled Balance Transfer Maintenance Functions .... 14 2.2.3. Logging Configuration ....................................................................... 14 3. Configuring the Predictive Forecasting Module ........................................................... 15 3.1. PF Configuration - Functional Overview .......................................................... 15 3.2. PF Configuration - Stream Positions ............................................................... 16 3.3. PF Configuration - Wholesale Positions ........................................................... 16 3.4. PF Configuration - Intersystem Deals .............................................................. 16 3.5. PF Configuration - RAG Alerts ...................................................................... 16 3.6. PF Configuration - Data Feeds ....................................................................... 16 3.6.1. Data Feeds - Streams ......................................................................... 17 3.6.2. Data Feeds - Wholesale ...................................................................... 17 3.7. PF Configuration - Semi-Static Data Maintenance ............................................. 17 3.7.1. Semi-Static Data Maintenance - Streams ............................................... 17 3.7.2. Semi-Static Data Maintenance - Wholesale ............................................ 18 3.8. PF Configuration - Static Data Maintenance ..................................................... 18 4. Configuring the Payment Flow Control Module ........................................................... 19 4.1. PFC - The Business Context .......................................................................... 19 4.2. Prioritization and Scheduling ......................................................................... 19 4.2.1. Overview of Prioritization and Scheduling ............................................. 20 4.2.2. Default Scheduling - Channel .............................................................. 20 4.2.3. Transaction-Specific Schedules ........................................................... 22 4.2.4. Relationship between Default Schedule and MetaSchedule ....................... 23 4.2.5. Main Output Variables Computed by LMS Used in Scheduling ................. 24 4.3. Release Processing ...................................................................................... 24 4.3.1. Release Processing Overview .............................................................. 24 4.3.2. Release Handler Components .............................................................. 26 4.3.2.1. Release Handler Component - Dispatcher ................................... 26 4.3.2.2. Release Handler Component - Releasor ...................................... 26 4.3.3. Transaction Selection ........................................................................ 27 4.3.3.1. Query Parameters ................................................................... 27 4.3.4. Cut-Off Processing ............................................................................ 28 4.3.4.1. Determining if a Transaction is Late .......................................... 29 4.3.4.2. Determining if a Channel is Open .............................................. 29 4.3.5. Status Codes .................................................................................... 33 4.3.6. Limits Processing ............................................................................. 35 iii Business Configuration Guide 4.3.6.1. Limit Utilization Criteria ......................................................... 36 4.4. PFC Configuration ...................................................................................... 37 4.4.1. Release Handler Configuration Diagram ............................................... 37 4.4.2. Starting Release Handler .................................................................... 37 4.4.3. PFC Configuration Files ..................................................................... 39 4.4.3.1. Configuring the rh-channels-contexts-list File ............. 39 4.4.3.2. Configuring the release.properties File ........................... 39 4.4.3.3. Configuring the release-py File ........................................... 42 4.4.4. PFC Workflow Configuration ............................................................. 45 4.4.4.1. Configuring Transaction Types ................................................. 45 4.4.4.2. Configuring Transaction Status Records ..................................... 45 4.4.4.3. Configuring TypeStatus Records ............................................... 46 4.4.4.4. Configuring Workflow Transitions ............................................ 46 4.4.4.5. Configuring Workflow States ................................................... 47 4.4.5. Limits Configuration ......................................................................... 47 4.4.5.1. Limit Group Maintenance ........................................................ 48 4.4.5.2. Cross Reference Maintenance ................................................... 48 4.4.5.3. Limits Maintenance ................................................................ 48 4.4.5.3.1. Stream Limits Maintenance ........................................... 48 5. Configuring the Collateral Manager Module ............................................................... 50 5.1. CMM - Data Requirements ........................................................................... 50 5.1.1. CMM - Semi-Static Data Requirements ................................................ 50 5.1.2. CMM - Static Data Requirements ........................................................ 50 5.1.3. CMM - Configuration Data Requirements ............................................. 50 5.2. CMM - Configuring Depositories ................................................................... 51 5.3. CMM - Issue Details Processing ..................................................................... 51 5.3.1. Ranking Issue Detail Fields ................................................................ 51 5.3.2. Two Streams in the Model .................................................................. 51 5.3.3. An Example of Ranking Issue Detail Fields ........................................... 52 5.4. CMM - Matching Configuration ..................................................................... 53 5.4.1. CMM - Automated Collateral Matching Information ............................... 53 5.4.1.1. Example of Collateral Rule Definitions ...................................... 55 5.4.1.2. Matching Amounts ................................................................. 55 5.4.1.3. Partial Matching or One-to-Many Matching ................................ 56 5.4.2. CMM - Matching Rules ..................................................................... 59 5.4.2.1. CMM Transaction Statuses ...................................................... 59 5.4.2.2. CMM Transaction Types ......................................................... 59 5.4.2.3. Notes Concerning the Design of the CMM Matching Rules ............ 61 5.4.2.4. An Example of Matching in the CMM Module ............................ 61 5.4.2.5. Duplicate Processing with CMM ............................................... 61 5.4.2.6. An Example of Duplicate Processing using CMM ........................ 62 5.4.2.7. Filter Rules with CMM ........................................................... 62 5.4.2.8. Matching Rule Configuration File ............................................. 63 5.4.3. CMM - Designating Pledgeable Channel Records ................................... 63 6. Post-Configuration Information ................................................................................ 65 6.1. Ensuring that Feeds are Properly Entering LMS ................................................ 65 6.2. Testing the LMS Business Configuration ......................................................... 65 6.3. Maintaining the LMS Business Configuration ................................................... 65 6.3.1. Maintenance Functions for the CFM Module ......................................... 65 6.3.1.1. CFM - Balance Transfer Maintenance Functions .......................... 66 6.3.1.2. CFM - Channel Support Maintenance Functions .......................... 66 6.3.1.3. CFM - Configuration Parameter Maintenance Functions ................ 66 6.3.1.4. CFM - Semi-Static Data Maintenance Functions .......................... 67 6.3.1.5. CFM - Static Data Maintenance Functions .................................. 67 6.3.1.6. CFM - System Management and Maintenance Functions ............... 67 6.3.2. Maintenance Functions for the PF Module ............................................. 68 6.3.2.1. PF - Configuration Parameter Maintenance Functions ................... 68 6.3.2.2. PF - Semi-Static Data Maintenance Functions .............................. 68 iv Business Configuration Guide 6.3.2.3. PF - Static Data Maintenance Functions ...................................... 68 6.3.3. Maintenance Functions for the PFC Module ........................................... 69 6.3.4. Maintenance Functions for the Liquidity Risk Manager ............................ 69 6.3.5. Maintenance Functions for the CMM Module ........................................ 69 6.3.5.1. CMM - Event Maintenance Functions ........................................ 69 6.3.5.2. CMM - Semi-Static and Static Data Maintenance Functions ........... 69 7. Workflow Monitoring and Position-Keeping Functionality ............................................ 71 7.1. CFM - Workflow Monitoring and Position-Keeping Functionality ........................ 71 7.1.1. CFM - Account Balances and Balance Management ................................ 71 7.1.2. CFM - Transaction Recording ............................................................. 71 7.1.3. CFM - Recording Transaction Status .................................................... 73 7.1.4. CFM - Status Change Actions ............................................................. 74 7.1.5. CFM - Positions and Calculations ........................................................ 74 7.1.6. CFM - Cash Positions ........................................................................ 74 7.1.7. CFM - Decision Support .................................................................... 75 7.1.8. CFM - Standard Position Views ........................................................... 75 7.1.9. CFM - Standard Transaction Inquiries .................................................. 75 7.2. PF - Workflow Monitoring and Position-Keeping Functionality ........................... 76 7.2.1. PF - Anticipated Stream and Wholesale Positions ................................... 76 7.2.1.1. PF - Stream Positions .............................................................. 76 7.2.1.2. PF - Projected Wholesale Positions ............................................ 77 7.2.2. PF - Standard Position Views .............................................................. 77 7.2.3. PF - Standard Transaction Inquiries ...................................................... 78 7.2.4. PF - Transaction Recording ................................................................ 78 7.3. CMM - Workflow Monitoring and Position-Keeping Functionality ....................... 78 7.3.1. CMM - Transaction Recording ............................................................ 78 7.3.2. CMM - Recording Transaction Status ................................................... 80 7.3.3. CMM - Partial Settlement ................................................................... 81 7.3.4. CMM - Status Change Actions ............................................................ 81 7.3.5. CMM - Collateral Positions ................................................................ 81 7.3.6. CMM - Projected Positions ................................................................. 83 7.3.7. CMM - Decision Support ................................................................... 83 7.3.8. CMM - Standard Position Views ......................................................... 83 7.3.9. CMM - Custom Views ....................................................................... 84 7.3.10. CMM - Standard Transaction Inquiries ................................................ 84 v About This Document Note The LMS product has been restructured under the new name of SAP Liquidity Management for Banking where two optional add-ons are available: SAP Payment Flow Control and SAP Collateral Management. In following SAP Liquidity Management for Banking and LMS will be used as synonyms. Following the installation and technical configuration of the Liquidity Management Suite (LMS), business analysts and other technical staff at the bank must configure the system to reflect the bank's environment. This document introduces users to the business configuration aspects of LMS, gives users some background into the various workflow monitoring and position-keeping functions of LMS, tells users how to configure LMS, and describes the maintenance functions of LMS. LMS is a highly configurable application. It adapts to your business needs. LMS is installed as a working model. Business Analysts should review and understand the model before beginning bank-specific configuration. See the LMS Data Model Reference Guide for more information about the LMS data model. Because LMS is so highly configurable and each customer has specific needs based on their business, it is not possible to cover every single configurable item. However, this document will cover the general configuration information for LMS and for each LMS module. To ease the business configuration process, this document is organized by LMS module. Therefore, you need only refer to information for those modules that you have purchased. 1. Purpose In general, Business Analysts, or those who initially configure LMS and tailor it to the bank's needs, will use this guide. Business Analysts bridge the gap between the technical and business aspects of the bank. They understand the bank's organization and business practices, the bank's liquidity management practices, and the bank's technology systems. In addition, Business Analysts understand the various Business Units of the bank and the information that must be entered in LMS so that the proper liquidity positions are created. When LMS is first introduced and installed at the bank, users will rely heavily on this document as they are configuring LMS to reflect their bank's environment. Following the initial implementation and configuration of LMS, Business Analysts will refer back to this document to manage ongoing system configuration and testing whenever business needs, data sources, and requirements change over time. In addition, Technical Team members and the IT infrastructure group may use this document to ensure that the proper feeds are coming into LMS. To learn more about the LMS data model, see the LMS Data Model Reference Guide. 2. CMM Module During the installation and technical configuration of LMS, we informed you of issues related to the CMM module that may affect LMS. These issues must be dealt with in order to use LMS successfully. vi Chapter 1. Performing High-Level Configuration Tasks This section describes how to perform high-level configuration tasks such as: • Defining RAG Rules • Configuring time zones 1.1. Defining RAG Rules You can configure LMS to warn you when certain conditions occur with your liquidity status, either in terms of specific monetary amounts or percentages of monetary amounts. For example, you can tell LMS to alert you when a position is much higher than you would expect at a specific time of the day (a Red Alert, something to be concerned about), somewhat higher (an Amber Alert, something to be aware of), or perfectly normal (a Green Alert, nothing to be concerned about). Alerts can also be based on transactions, and are the sole means of alerts that payments have not been made or received in LMS. Configuring such warnings is called configuring RAG Rules. RAG Rules are sets of rules or stipulations you assign to various values such as amounts or percentages. When these rules are breached, LMS sends Liquidity Managers a warning that the condition has been met. In essence, RAG Rules are a color-coded alert system. RAG stands for Red, Amber, and Green. Each is described below: • Red Alert: When a critical condition is reached, the Liquidity Manager would see the number with a Red background, the most-crucial type of alert. In this case, the Liquidity Manager would want to take immediate action to remedy the issue, depending on the bank's policies. • Amber Alert: When a semi-critical condition is reached, the Liquidity Manager would see the number with an Amber background, a less-critical type of alert. In this case, the Liquidity Manager might want to continue to monitor the situation, but may not need to take action, depending on the bank's policies. • Green Alert. When neither of the above conditions are reached the Liquidity Manager will leave the numbers in their normal state, no highlighting will occur. RAG Rules relate only to the following positions: 1. Projected Wholesale Positions 2. Stream Detail 3. Cash Transactions In addition, the PFC Module has some alert functionality built into it, so that a Liquidity Manager can be alerted when a transaction exceeds a limit, or when a manual intervention is made to a transaction awaiting release. RAG Rule Example Based on Currency Below is an example of a RAG rule configuration. In this example, there are two currencies involved, Great Britain pounds (GBP) and Euros (EUR). After you review this entire RAG Rule, we will review one section of this RAG Rule and translate it, so you know what it means. 1 Performing High-Level Configuration Tasks 150000 75000 4500000 3000000 50 20 100000 50000 7000000 5000000 Specifically, look at this section of the RAG Rule. 4500000 3000000 This rule indicates that one hour before Currency Close (Defined on the Currency Table): • If the position balance is above 4.5 million, the position/number will be highlighted in Red. The Liquidity Manager will be aware of this critical position and will take immediate action. • If the amount of the position is between 3 million and 4.5 million, the position/number will be highlighted in Amber. The Liquidity Manager will be aware of this somewhat important position and may take action. • If the position balance is below 3 million, no highlighting will occur. The Liquidity Manager will know that this position is acceptable and no action need be taken. RAG Rule Example Based on Percentage Below is another RAG Rule that is based on percentages, instead of actual monetary amounts. The calculation is: Anticipated Remaining Amount/ Anticipated Net * 100. 50 20 RAG Rule Example: Projected Wholesale Position The following is a RAG Rule example based on projected wholesale positions. Wholesale Transactions are those which have been captured using Wholesale Anticipated Event Maintenance or through Transaction Maintenance with the Originating system with both Funding and Money Market defined as YES. 150000 75000 4500000 3000000 50 20 100000 50000 7000000 5000000 RAG Rule Example: Stream Detail The following is a RAG Rule example based on stream details. 30000000 20000000 50000000 40000000 54000000 20000000 35000000 25000000 50000000 40000000 60000000 50000000 100000000 80000000 20000000 10000000 20000000 10000000 The decision whether to RAG is a calculation based on: Opening Balance + Selected Products +Anticipated. RAG Rule Example: Cash Transactions The following is a RAG Rule example based on cash transactions. 1.0 0.30 0.30 0.15 4.0 2.0 4 Performing High-Level Configuration Tasks 999999 262800 1.0 0.30 8760 720 1.2. Configuring Time Zones Time zones are configured as Locations using the Location Maintenance function. The function captures time zones as named locations with data input as illustrated in the following table. Location Name Time Zone BRU Brussels Europe/Brussels CET Central European Time CET LN London Europe/London NY New York America/New York TKY Tokyo Asia/Tokyo The list of time zones is taken from a java library delivered with LMS, which is available as a dropdown list in the maintenance function. 5 Chapter 2. Configuring the Cash Flow Manager Module 2.1. CFM Configuration - Cash Transaction Matching Rules The Matching Rules, held in thematchrules.conf file found in the lms/conf/business directory, are in three parts: 1. Filtering – Determine if the record should be subjected to matching or ignored by the matching module. 2. Selection – Based on the values of various fields of the incoming record, determine a (candidate transaction set, match rule) pair that is applicable. The selection phase of matching is also used in the determination of transactions that are “self matched.” Self-matches can be determined from the ”Incoming” clauses of a selection rule, and the incoming transaction exclusively. 3. Matching - Use the (candidate transaction set, match rule) pair to determine if a match exists. The match rule is evaluated on the incoming record and each of the records in the candidate transaction set, stopping when a match occurs or all records of the set are exhausted. The following are configured in the LMS MatchType table.The Duplicate State column indicates which transaction is to be considered as a Duplicate. The two character codes relates to CFM/PFC Transaction Types and the three character codes relate to the CM transaction Types FromType ToType Duplicate State AR ER No Duplicate AR GR No Duplicate AR PR No Duplicate AR RR No Duplicate EP PP To Type ER AR No Duplicate ER PR To Type GP PP To Type GR AR No Duplicate GR PR To Type PP EP From Type PP GP From Type 6 Configuring the Cash Flow Manager Module FromType ToType Duplicate State PP RP From Type PR AR No Duplicate PR ER From Type PR GR From Type PR RR From Type RP PP To Type RR AR No Duplicate RR PR To Type Any two fields in the Transactions table can be used. The fields can be distinct (for example, compare the DR Account to the CR Account). Currency and value date are mandatory and possibly implicit. The system must never match events with different dates and currencies. The transaction type can be implicit in the matching rule, since the selection rules define what types are being compared. 2.1.1. Rule Definition Information Rules are defined using fairly regular grammar in a text file. Upon startup, the matching module reads this text file. In the following rules descriptions, the bracketed items (in [ ]) are optional. 2.1.1.1. Filtering Rules Filtering rules are specified using the syntax show below. Zero or more of these rules may be present in the rules file. They are negative in nature. For example, for an incoming transaction, if all the field: Boolean of a given rule evaluate to true, then the record is filtered out and not passed on to the internal matching engine proper. filter { ID: field: ... field: } 2.1.1.2. Selection Rules Selection rules are specified using the syntax shown below. Zero or more of these rules may be present in the rules file. Once read into the matching engine, they are ordered by priority (specified using the priority: attribute of a selection rule). 7 Configuring the Cash Flow Manager Module selection { ID: priority: incoming: ... incoming: [existing: ] ... [existing: ] [selfmatch: 0|1] [matchrule: ] } The incoming: boolean clauses are applied to the incoming record. If all the incoming clauses evaluate to true, the selection rule is deemed appropriate for the incoming record. To determine what subset of existing records should be considered for possible matching, the existing: boolean statements are used. The subset that passes all of the existing: statements is the subset that is suitable for possible matching with the incoming record. When the selfmatch: flag is set, any existing: rules, and the matchrule: are ignored. In this case, the selection criteria is strictly on the incoming transaction, and if all incoming: rules are satisfied, the transaction is said to match itself. NOTE: Since the existing: clauses of selection rules are fixed at parse time, we can generate a row set for each selection rule that represents the records of the transaction table that pass the existing: clause. This will eliminate the need to run the existing: clause at match time in order to determine candidate matches. The only issue is maintenance of these row sets, which is a relatively straightforward task. Selection rows sets are maintained using the following logic: • If a transaction is deleted, it is removed from any selection row set that it is currently in. • If a transaction is updated, or inserted, we run the existing: clause of each selection rule against it, deleting it from the selection row sets whose existing: clause fails, and inserting it into all row sets whose existing: clause passes. • When a filter rule evaluates true on an incoming transaction, and its ignore field is set to hardIgnore(2), remove the transaction from all selection row sets. 2.1.1.3. Matching Rules A matching rule has the following structure. It is specified via a selection rule that contains a link to a match rule via its matchrule: field. match{ ID: tolerance: match: ... match: matchtype: {regular|duplicate} } A match type of “regular” is the normal mode of operation and is used to generate match records between different transactions. There may be cases where one detects, via a match rule, that two transactions should be made synonymous (for example, they are different representations of the same transac8 Configuring the Cash Flow Manager Module tion, and one of them should be ignored (with respect to matching and position computations)). Setting the matchtype: field to “duplicate”, specifies rules of this type. The combination of selection/match rules for duplicate detection should run at a higher priority then any regular match rules, or there is a chance of a regular match occurring, and the duplicate transaction slipping by undetected. 2.1.2. Constants There are two types of constants: real constants and character constants: • Real constants (those associate with a real value column) may include an optional decimal point. For example, “incoming: Original Amount < 10000” or “incoming: Original Amount < 10000.0” would parse the numeric constants 10000 and 10000.0 as real values since the Original Amount column in the transaction table is of real type. • Character constants without embedded spaces need not be quoted. Embedded spaces are required in date specifications. For example, ‘incoming: Value Date <“2004-04-01 00:00:00”’ would behave as expected, but ‘incoming: Value Date < 2004-04-01 00:00:00’ would not as the date constant has an embedded space, and would be removed at parse time due to the fact that it is not quoted. 2.1.3. Operators and Tolerances Allowed operators are {=, !=, <, >, :odd: , :in:}. Numeric comparison with a tolerance means |value1 - value2| < tolerance. It is only applied for the equality (=) operator, and when the field type is determined to be numeric. If the is “:in:”, then should be a list, e.g., [CA,DU] or [100, 200, 345]. The following is a commented example illustrating the syntax of the rules configuration language and its base functionality. Actual implementation may vary. Sample Rule Configuration File # Matching Rule configuration file # # Filtering Rules # # This filtering rule blocks selected transaction types from match processing # filter { ID: 1 field: TransactionType :in: [AB,AC,AD,CB,OB,SP,SR,WP,WR] } # # This filtering rule blocks selected transaction statuses from match processing # filter { ID: 2 field: AdapterStatus :in: [BC,BP,BX,CA,NC,NR,NX,RO] } # # This filtering rule blocks reversed transactions # filter { ID: 3 field: Reversed = 1 } # 9 Configuring the Cash Flow Manager Module # Selection Rules # # If the incoming receipt is an Expected, Netting or Rolled Receipt, # look at all existing Pending Receipts and run Match Rule 100 against # the resulting pairs (duplicate detection) # selection { ID: 10 priority: 1 incoming: TransactionType :in: [ER,GR,RR] existing: TransactionType = PR selfmatch: 0 matchrule: 100 } # # If the incoming receipt is a Pending Receipt, look at all existing # Expected, Netting or Rolled Receipts and run Match Rule 200 against # the resulting pairs (duplicate detection) # selection { ID: 11 priority: 1 incoming: TransactionType = PR existing: TransactionType :in: [ER,GR,RR] selfmatch: 0 matchrule: 200 } 2.2. CFM Configuration - Balance Transfers LMS Balance Transfer functionality allows the bank to move funds from one channel to another. There are two types of balance transfers: Manual Balance Transfer (MBT) functionality is provided to initiate ad hoc transfers. Scheduled Balance Transfer (SBT) functionality is provided to automatically initiate scheduled transfers between accounts. The Scheduled Balance Transfer process cycles at the frequency configured, checking if there are transfers to be initiated. The configuration of Balance Transfer functionality includes: • Scheduled Balance Transfer Configuration. • Balance Transfer Adapter Configuration Internally, the following steps are performed when a balance transfer is initiated. • The Scheduled Balance Transfer service (for a scheduled transfer) or Manual Balance Transfer screen (for a manual transfer) generates an internal message in MQ format which is sent to the special MQ queue LMS_IBalTran. • The Adpt_baltran adapter listens to this queue and creates outbound messages for each incoming message received. The default configuration includes templates to generate internal events for the expected payment/receipt events. It is also possible to configure the adapter to generate messages to external systems in appropriate format (for example, SWIFT). 2.2.1. Balance Transfers - Scheduled Balance Transfer Configuration 10 Configuring the Cash Flow Manager Module The baltran.properties file in /lms/conf/business contains the following settings: #################################################################### # # Scheduled Balance Transfer Service configuration file # #################################################################### Platform.Hostname=wey.lmsdmz.local Platform.Port=21499 Platform.SQL.Port=21400 Platform.User=tst214uk # Uncomment the following line to use clear-text password in NORMAL authentication mode # Platform.Password= Platform.SQL.Connections = 5 # Platform authentication mode: NORMAL or RSA Platform.AuthMode=RSA CredentialsFolder=/aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/.keystore MQ.Hostname = lms.lmsdmz.local MQ.QueueManager = QM_TST214UK_WEY MQ.Channel = S_LMS_WEY MQ.Port = 21440 # MQ.User = mqm # MQ.Password = mqm1234 MQ.Queue.Baltran = QUEUE_LMS_BALTRAN # - File sink for testing and debugging # File.Output.Baltran = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/output/baltran-out.xml These are standard communication parameters that are configured automatically during the installation process. 2.2.2. Balance Transfers - Adapter Configuration (adpt_baltran) The adpt_baltran.properties file contains the adapter configuration required to connect from the Scheduled Balance Transfer or Manual Balance Transfer process to the Outbound Formatter. The file is found in lms/conf/adaptor_props. The following is an example of the adpt_baltran.properties file. ############################################################################## # # Balance Transfer Outbound Formatter Properties File # ############################################################################## # Uncomment to use MQ authentication with encrypted password # #include /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/.keystore/pwd_mq.cfg #----------------------------------------------------------------------------# Controller definitions #----------------------------------------------------------------------------adpt_baltran.Controller.Name = AleriController adpt_baltran.Controller.ClassName = com.aleri.adaptor.ALRController adpt_baltran.Controller.Context.Name = AleriContext #adpt_baltran.Logging.LogSetting1=DEBUG org.openadaptor.dostrings # Uncomment for file-based input #adpt_baltran.FileSource.LinkTo++ = PaymentFileSink #adpt_baltran.FileSource.LinkTo++ = ReceiptFileSink # Uncomment for file-based output 11 Configuring the Cash Flow Manager Module #adpt_baltran.MQSource.LinkTo++ = PaymentFileSink #adpt_baltran.MQSource.LinkTo++ = ReceiptFileSink adpt_baltran.MQSource.LinkTo++ = PaymentMQSink adpt_baltran.MQSource.LinkTo++ = ReceiptMQSink adpt_baltran.Controller.SecurityManager.ClassName = com.aleri.adaptor.security.PasswordEncryptor adpt_baltran.Controller.SecurityManager.KeyStore = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/.keystore/universal.der adpt_baltran.Controller.SecurityManager.KeyStoreType = PKCS8 #----------------------------------------------------------------------------# MQ Source #----------------------------------------------------------------------------adpt_baltran.Component++.Name = MQSource adpt_baltran.MQSource.ClassName = com.aleri.adaptor.mq.AleriMqSource adpt_baltran.MQSource.DOStringReader = com.aleri.adaptor.dostrings.LmsMessageReader adpt_baltran.MQSource.PollPeriod=30000 adpt_baltran.MQSource.Field++ = ValueDate adpt_baltran.MQSource.Field++ = Amount adpt_baltran.MQSource.Field++ = CaptureDateTime adpt_baltran.MQSource.ValueDate.Type = Date adpt_baltran.MQSource.Amount.Type = BigDecimal adpt_baltran.MQSource.CaptureDateTime.Type = Date adpt_baltran.MQSource.MqManagerName = QM_TST214UK_WEY adpt_baltran.MQSource.MqHostName = lms.lmsdmz.local adpt_baltran.MQSource.MqPort = 21440 #adpt_baltran.MQSource.MqUserName = mqm #adpt_baltran.MQSource.MqPassword = ${MQ_PWD} adpt_baltran.MQSource.MqChannelName = S_LMS_WEY adpt_baltran.MQSource.MqQueueName = QUEUE_LMS_BALTRAN adpt_baltran.MQSource.PollLogFrequency = 100000 #----------------------------------------------------------------------------# File Source #----------------------------------------------------------------------------#adpt_baltran.Component++.Name = FileSource #adpt_baltran.FileSource.ClassName = com.aleri.adaptor.standard.FileBatchSource #adpt_baltran.FileSource.DOStringReader = com.aleri.adaptor.dostrings.LmsMessageReader #adpt_baltran.FileSource.InputFileName = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/init/data/baltran-input.xml #adpt_baltran.FileSource.PollPeriod=30000 #adpt_baltran.FileSource.Field++ = ValueDate #adpt_baltran.FileSource.Field++ = Amount #adpt_baltran.FileSource.Field++ = CaptureDateTime #adpt_baltran.FileSource.ValueDate.Type = Date #adpt_baltran.FileSource.Amount.Type = BigDecimal #adpt_baltran.FileSource.CaptureDateTime.Type = Date #----------------------------------------------------------------------------# ReceiptMQSink #----------------------------------------------------------------------------adpt_baltran.Component++.Name = ReceiptMQSink adpt_baltran.ReceiptMQSink.ClassName = com.aleri.adaptor.mq.AleriMqSink adpt_baltran.ReceiptMQSink.MqManagerName = QM_TST214UK_WEY adpt_baltran.ReceiptMQSink.MqHostName = lms.lmsdmz.local adpt_baltran.ReceiptMQSink.MqPort = 21440 #adpt_baltran.ReceiptMQSink.MqUserName = mqm #adpt_baltran.ReceiptMQSink.MqPassword = ${MQ_PWD} adpt_baltran.ReceiptMQSink.MqChannelName = S_LMS_WEY adpt_baltran.ReceiptMQSink.MqQueueName = QUEUE_LMS_EVENTS adpt_baltran.ReceiptMQSink.SimulateOnly = false adpt_baltran.ReceiptMQSink.DOStringWriter = org.openadaptor.dostrings.XSLStringWriter adpt_baltran.ReceiptMQSink.Stylesheet = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/conf/adaptor_props/output/ platform/baltran-er.xsl #----------------------------------------------------------------------------# PaymentMQSink #----------------------------------------------------------------------------adpt_baltran.Component++.Name = PaymentMQSink adpt_baltran.PaymentMQSink.ClassName = com.aleri.adaptor.mq.AleriMqSink adpt_baltran.PaymentMQSink.MqManagerName = QM_TST214UK_WEY adpt_baltran.PaymentMQSink.MqHostName = lms.lmsdmz.local adpt_baltran.PaymentMQSink.MqPort = 21440 12 Configuring the Cash Flow Manager Module #adpt_baltran.PaymentMQSink.MqUserName = mqm #adpt_baltran.PaymentMQSink.MqPassword = ${MQ_PWD} adpt_baltran.PaymentMQSink.MqChannelName = S_LMS_WEY adpt_baltran.PaymentMQSink.MqQueueName = QUEUE_LMS_EVENTS adpt_baltran.PaymentMQSink.SimulateOnly = false adpt_baltran.PaymentMQSink.DOStringWriter = org.openadaptor.dostrings.XSLStringWriter adpt_baltran.PaymentMQSink.Stylesheet = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/conf/adaptor_props/output/ platform/baltran-ep.xsl #----------------------------------------------------------------------------# ReceiptFileSink #----------------------------------------------------------------------------#adpt_baltran.Component++.Name = ReceiptFileSink #adpt_baltran.ReceiptFileSink.ClassName = org.openadaptor.adaptor.standard.FileSink #adpt_baltran.ReceiptFileSink.OutputFileName = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/output/baltran-er-out.xml #adpt_baltran.ReceiptFileSink.DOStringWriter = org.openadaptor.dostrings.XSLStringWriter #adpt_baltran.ReceiptFileSink.Stylesheet = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/conf/adaptor_props/output/ platform/baltran-er.xsl #----------------------------------------------------------------------------# PaymentFileSink #----------------------------------------------------------------------------#adpt_baltran.Component++.Name = PaymentFileSink #adpt_baltran.PaymentFileSink.ClassName = org.openadaptor.adaptor.standard.FileSink #adpt_baltran.PaymentFileSink.OutputFileName = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/output/baltran-ep-out.xml #adpt_baltran.PaymentFileSink.DOStringWriter = org.openadaptor.dostrings.XSLStringWriter #adpt_baltran.PaymentFileSink.Stylesheet = /aleri/home/tst214uk/v6.1.1-esp/lms_services/lms/conf/adaptor_props/output/ platform/baltran-ep.xsl LMS is delivered with example templates for creating the messages to be sent as defined in the example above. The following are example templates: • baltran-ep.xsl – Found in /lms/conf/adaptor_props/output/platform , the file defines how to create event input to the LMS preprocessor for an expected payment. • baltran-er.xsl – Found in /lms/conf/adaptor_props/output/platform , the file defines how to create event input to the LMS preprocessor for an expected receipt. The configuration outlined above creates four outbound messages that create the following in LMS: • An Expected Payment • An Expected Receipt It is likely that the outbound message configuration will be modified during implementation to send appropriate messages to the bank’s existing payment system(s) to create the required payment, receive messages, a normal payment order, and generate required accounting entries. It is also possible to generate the outbound messages to be sent to the bank’s messaging gateway(s), and a pair of appropriate accounting entries to be sent to bank’s accounting system. 2.2.2.1. Configuring the Poll Period The poll period is the parameter that defines the interval at which the adapter will check the message queue to see if there are new messages concerning scheduled balance transfers. If there are new messages, the system processes the messages. This parameter defines the time that will lapse (that is, the break that the adapter will take) before the system will check again for new messages. The assignment of a poll period controls efficiency. In other 13 Configuring the Cash Flow Manager Module words, the system is not constantly checking for new messages. Instead, it will check for messages at a regular interval (the poll period), depending on the needs of the bank. To configure the poll period: 1. In the lms/conf/adaptor_props/adpt_baltran.properties file, you will find the following parameter: adpt_baltran.MQSource.PollPeriod= . 2. In the space following the = , enter the number of milliseconds, based on the needs of the bank. For example, enter the number 30000, if you want the system to check for messages every 30 seconds. For example, if you want the system to check for messages every 30 seconds you would enter adpt_baltran.MQSource.PollPeriod=30000 2.2.2.2. Maintaining Scheduled Balance Transfer Maintenance Functions Three maintenance functions are used in the capture, update, and deletion of Scheduled Balance Transfers. They are found in the Data Maintenance Balance Transfers menu. • Scheduled Balance Transfer – Establishes the details of a regular transfer between two channels, of the same currency, at a specified time and cycle. For example, it can generate a transfer to level the balance in Channel 1 against Channel 2 at 15:00 each business day. • Balance Transfer Rules – Establishes a set of rules that determine whether or not a balance transfer should take place. For example, rules can be set to generate the transfer only when the balance of the account is greater, less or equal to a predetermined balance. • Transfer Set Maintenance – Groups together Channels of the same currency, for instance when it is required to bring all JPY Channels to Zero each day and transfer the balance to / from a main JPY account. When capturing a balance transfer for currencies in different time zones, care needs to be taken to ensure that the target channels are open at the time the transfer is to be made. Channel open times are defined in the channel record and are at times local to the location of the channel. 2.2.3. Logging Configuration In order to trace activities related to Balance Transfers (including generated messages) the following log files could be analyzed: • lms/output/log/baltran.log – log of Scheduled Balance Transfer service. The logging configuration is in the lms/conf/log4j.properties file (Scheduled Balance Transfer section) • lms/output/log/adpt_baltran.log – log of adpt_baltran adapter. The logging configuration is in the lms/conf/log4j.properties file (Adapters section) • Web-application log file. The location of this file depends on application server used and its configuration. The logging configuration is in the < WEB App Root > / WEB-INF/classes/log4j.properties file. 14 Chapter 3. Configuring the Predictive Forecasting Module 3.1. PF Configuration - Functional Overview The Predictive Forecasting Module of LMS (PF) provides a multi-entity, multi-currency capability to monitor positions for internal and external parties, and to predict (anticipate) cash flows in or out of those positions that are either un-contracted or not yet ordered. To perform this function, the module creates, in real time, the cash positions for selected internal trading (wholesale) and internal or external account based (stream) parties, using data concerning the parties already included in the transactions processed by the LMS Cash Flow Manager Module (CFM). This allows users to monitor the positions in real time and capture anticipated movements into or out of those positions. To configure the Predictive Forecasting Module, the bank must consider: • Data Feeds to ensure that the data in events include in addition to other payment details: • Debit and Credit Account information, • Originating System information, • Responsible Business Unit information, • Responsible Dealer information • Semi-Static Data Maintenance • Business Unit • Counterparty • Dealer Currency • Stream Customer Account • Stream Customer • Sort Code • Stream • Stream Customer Default Anticipated • Static Data Maintenance • Cross Booking Lines • Configuration Parameter Maintenance • Product • Stream Movement Type • Alerts 15 Configuring the Predictive Forecasting Module 3.2. PF Configuration - Stream Positions The following summarizes stream positions: Stream - regroups -> Customer/Business Unit (BU) – Who owns-> Accounts. A stream regroups customers or BU within the bank, which have a number of accounts. Cash flows create debits or credits to these accounts, and are categorized by products, the product being roughly the source system for the cash flow (for example, CHAPS, Clearing, FX settlements, and so on). The product is either implicit from the source of the data or (sometimes) explicitly specified as a product type by the feed itself. A movement could impact two streams (DR and CR side). 3.3. PF Configuration - Wholesale Positions Wholesale positions are derived from the deal cash movements via the counterparty. The sources of the information are the deals from the Money Market system (bookings), Product Processing systems, and anticipated movements. When a department (or Business Unit) is long or short, it will pass this position to treasury/Money Market. Money Market will in turn give or take a deposit for this amount. The same reasoning applies to customers of the bank based upon anticipated flows. The wholesale area is divided per "activity" or Business Units (BU), such as Commodities, Forex, Derivatives, and so on. The BU is determined by the counterparty. LMS holds the relationship BU to counterparty in a user-maintainable table, with the indication of whether a multiple or single bookings are expected. When the counterparty is not identified within this table, LMS will check a second relationship (Dealer + Currency) to Business Unit , and if found, will position the movement in this line as anticipated. 3.4. PF Configuration - Intersystem Deals LMS receives feeds from multiple systems, and on occasion deals are booked between several participating systems. For example, when deposits are booked between Group Treasury and Investment Bank Treasury, the deal will be entered in Money Market systems in both BUs. The same could occur between Fixed Income and Money Market system(s). This requires special processing to ensure that movements are not double-counted in the Overall Positions. To enable this, the Bank will need to create “Cross Booking Line” records. 3.5. PF Configuration - RAG Alerts Predictive Forecasting allows alerts to be generated when the balances in either the internal trading (wholesale) positions or the selected account (stream) positions exceed configured thresholds. Threshold based screen alerts can be configured for both Stream and Wholesale positions via rules described in detail in the Section 1.1, “Defining RAG Rules” section above. The configuration files are found in the web application (Tomcat or WebSphere) directory in / webapps/Conf. • WholesalePositions.xml contains the rules that apply to Wholesale Positions. • StreamDetail.xml contains the rules that apply to Stream Customer positions. 3.6. PF Configuration - Data Feeds The base data used in Predictive Forecasting is provided by Source Systems and is mapped into LMS 16 Configuring the Predictive Forecasting Module Events. The following subsection describes the data fields that must be populated by the source data. 3.6.1. Data Feeds - Streams The following are stream data feeds: • Event.CRAccountName – Optional. The Account Name • Event.CRNumber – Optional. The Account Number • Event.CRSortCode – Required. The Business Unit or Branch at which an account is held • Event.DRAccountName – Optional. The Account Name • Event.DRNumber – Optional. The Account Number • Event.DRSortCode – Required. The Business Unit or Branch at which an account is held • Event.Product – The product involved in the transaction • Event.StreamMovementType – Another indication of the product involved in the transaction. This will usually be an indication of the type of settlement. For example, RTGS, Net Clearing, Cheque Clearing, Payroll, and so on. 3.6.2. Data Feeds - Wholesale The following are wholesale data feeds: • One of Counterparty or Dealer is required. If both are entered, normally the Counterparty will be used for position calculation. • Event.Counterparty – Optional. The name of the business unit responsible for the transaction. • Event.Dealer – Optional. The Dealer responsible for the trade. • Event. OriginatingSystem – Required. The system in which the transaction originated. This is used to generate the correct Wholesale position. 3.7. PF Configuration - Semi-Static Data Maintenance Predictive Forecasting is delivered with functions to Capture, Update, and Delete the Semi-Static data required by the module to produce the desired positions. The following section describes the functions and the underlying data. However, the data to be entered into the tables must be determined as part of the pre-implementation tasks. It is often more effective to use spreadsheets to load the initial data to LMS, using the Maintenance functions for marginal changes over time. 3.7.1. Semi-Static Data Maintenance - Streams The following is semi-static data maintenance stream information: • Stream Maintenance – Used to define the party groups of business units, customers, and customer 17 Configuring the Predictive Forecasting Module accounts for which positions are to be kept. • Stream Customer Maintenance – Used to relate Customer Names to Streams (groups of customers). • Sort Code Maintenance – Used to relate the Business Units in which accounts are held to Streams (party groups). The data can be numeric-only or alphanumeric. It may be defined in a particular banking market such as UK Sort Code or US Transit Routing Codes. It may be some internal naming convention. It uses the CR and DR SortCode Data from transactions. • Stream Customer Account Maintenance – Used to relate Sort Code and Account Number combinations to Customer Names defined as Stream Customers. A Stream Customer may have multiple Stream Customer Accounts. • Stream Customer Default Anticipated – Used to record any default values to be used in generating anticipated movements against Stream Customer Accounts. 3.7.2. Semi-Static Data Maintenance - Wholesale The following is semi-static data maintenance wholesale information: • Business Unit Maintenance – Used to define the Business Units whose activity will generate wholesale position movements • Counterparty Maintenance – Used to define the relationship between transaction counterparty names to Business Units and Originating System. • Dealer Currency Maintenance – Used to define the relationship between Transaction Dealers and Business Units for which wholesale positions are generated. 3.8. PF Configuration - Static Data Maintenance There are no Static Data Maintenance functions for Stream processing. The following are Static Data Maintenance functions that impact Wholesale position processing: • Cross Booking Lines Maintenance – Used to define the relationship between Counterparty and Originating Systems to allow balancing movements to be generated by LMS when an internal transaction can be reported by two Originating systems. For example, when an internal trade between the FOREX department and the FUNDING department is recorded in both the FOREX system and the Money Market system. • Originating System Maintenance – Used to define the systems in which Wholesale transactions may originate. The Originating Systems determine whether wholesale positions should be generated in LMS or not. 18 Chapter 4. Configuring the Payment Flow Control Module The following subsection describes how to configure the PFC module. In particular, it describes: • Prioritization and Scheduling • Release Processing • The actual PFC Configuration 4.1. PFC - The Business Context The LMS Payment Flow Control (PFC) module forwards payment messages to existing payment processing systems to initiate the release of payments to selected Channels, or, optionally, to selected gateways for the external payment processing environment. The release of payments is based upon the available liquidity positions at the Channel, and debit cap limits set by the Channel and against payment counterparties. The PFC module provides for the following generic functions, where applicable, to support a channel: • Set limits. • Record cutoff times. • Message validation. • Release processing. • Rerouting. • Transmission. • Request information. • Process responses. • Process incoming payments. • Reconciliation. As noted earlier, this document describes only the PFC configuration and the required Static data and Semi-Static data required for the following processing elements of PFC: Scheduling, Release Processing, and Limit Checking. Details of the online functions that support PFC functionality can be found in the LMS Users Guide . 4.2. Prioritization and Scheduling The following subsection describes prioritization and scheduling as it pertains to the PFC Module. The objective of prioritization and scheduling is to create an ordered sequence of payments that follows a set of conditions and priorities. 19 Configuring the Payment Flow Control Module 4.2.1. Overview of Prioritization and Scheduling Within the PFC payment workflow, prioritization and scheduling calculations take place before Release Handler processing. The Release Handler uses the result of the current process to determine which payment should be considered next for release. Essentially, the Release Handler selects items ordered by priority or ordered by scheduled time. The Release Handler independently considers payments prioritized and payments scheduled by time. The result of the prioritization and scheduling also allows more accurate positioning. Different algorithms can be applied to the payments. In the base implementation, SAP directs the choice of algorithms via keywords applied to the transactions, keywords that can be supplied by the sender or the Adapters. Platform rules perform the calculations in the platform. Priority and scheduling are linked, since high priority items should be scheduled to execute before lower priority items. However, since the execution time may be a contractual constraint, the scheduling does not always derive directly from the priority and is treated somewhat distinctly. Logically, we split payments into the following two categories: • Prioritized payments – This category corresponds to the creation of a sequence of payments to be released. From this sequence, the system establishes a predicted release time, and finally, releases the movement. The order of a given transaction within that sequence depends on the transaction itself and on other characteristics of the transaction (for example, the transaction amount or the channel to which the transaction is to be sent). • Timed payments – This category is the direct allocation of release times for specified transactions. The system distinguishes the scheduled time (for example, when the system should execute the payment) versus the predicted time when the payment will be executed, based on the currently known information. The predicted time is obviously much more volatile. To order the payments, the system allocates to each movement a coefficient s that corresponds to the effective position in the list of all movements. The sequence is then achieved by listing all movements ordered by s , where the highest value of s is at the top of the queue. 4.2.2. Default Scheduling - Channel The following keywords are stored in Channels.DefaultSchedule . They control the choice of sequencing method for transactions that are not scheduled by time. For a Channel, we can have different scheduling algorithms, depending on the time of day. In practice, we have up to three different algorithms, and all three computations are performed at the same time by the data model. Channels.DefaultSchedule[n] specifies the algorithm to use. The following table outlines the valid algorithms, called DefaultSchedules : Name Description Timed or Sequenced FIFO First in First out Sequenced LIFO Last in First out Sequenced 20 Configuring the Payment Flow Control Module Name Description Timed or Sequenced PRIORITY-AMOUNT Priority, then decreasing amount Sequenced PRIORITY+AMOUNT Priority then increasing amount Sequenced PRIORITY-PARTYCATEGOR-AMOUNT Priority then descending party category then descending amount Sequenced The general naming convention will be the name of the attributes, separated by: • + if the order is increasing. • - if the order is decreasing. FIFO As a reference, we use the Transaction ProcessedDateTime . This is computed by the Preprocessor. The following table pertains to FIFO: Attribute Maximum Expression ProcessedDateTime 32,535,259,200 32,535,259,200-ProcessedDateTime f(x)=32,535,259,200-ProcessedDateTime LIFO The following table pertains to LIFO: Attribute Maximum Expression ProcessedDateTime N/A ProcessedDateTime f(x)=ProcessedDateTime PRIORITY-AMOUNT The following table pertains to PRIORITY-AMOUNT. This means "sort by priority and then by decreasing amount." For example, the largest amount is first. Attribute Maximum Expression ExternalPriority 10 11 - ExternalPriority 21 Configuring the Payment Flow Control Module OriginalAmount*100 999,999,999,999*100 OriginalAmount*100 PartyCategory 3 4 - PartyCategory f(x)=(11 - ExternalPriority)(999,999,999,999*100+1) + OriginalAmount*100 PRIORITY+AMOUNT This means "sort by priority and then by increasing amount." The following is an example: f(x)=(11 - ExternalPriority)(999,999,999,999*100+1) + (999,999,999,999*100-OriginalAmount*100) 4.2.3. Transaction-Specific Schedules It is possible to use any variable, but the following variables may be more useful: • ProcessedDateTime (Transactions) INPUT – This is the time when the top event was processed. This can be used as a reference time to count from in FIFO/LIFO-type operations. The time is allocated by the Preprocessor. NOTE: If the Transaction is updated, then this time changes. • ExternalPriority (Transactions) INPUT – This is the priority supplied externally to LMS. For example, a user may decide that a payment is especially urgent. This would be indicated in this variable. NOTE: The convention is that 1 indicates "Most urgent" and 9 is the lowest level of urgency. This does not imply that as many degrees of urgency need to be supported by external systems. • MetaSchedule (Transactions) INPUT – This is used to indicate that the transaction does not follow standard rules for the Channel. This would be filled in externally (that is, via a capture function or through a feed). The following table lists the possible values for MetaSchedule. Name Description Timed or Sequenced Base Delivery ASAP Forces scheduling by Com- Sequenced puted Priority (Default), using Channel settings. Yes ALAP An execution time is sup- Timed plied on the payment. The payment will be released at the latest possible time before this time, adjusted by lead time. Yes FIXED An execution time for reTimed lease is supplied in the pay- Yes 22 Configuring the Payment Flow Control Module Name Description Timed or Sequenced Base Delivery ment. NOTBEFORE At this stage of the imple- Timed mentation, this does not differ from FIXED from the standpoint of automatic scheduling. However, this will be checked within the release manager. Yes NOTAFTER An execution time is sup- Timed plied in the payment. The payment will be released at the latest possible time before this time. Yes Each of the above is described below in greater detail. ASAP ASAP (as soon as possible) is the default. This will override any scheduled time entered. ALAP Take the OriginalScheduledTime and adjust by Channel Lead time. FIXED OriginalScheduleTime is used to compute CalculatedScheduleTime . NOTBEFORE This is the same as fixed. CalculatedScheduleTime is set to OriginalScheduleTime . NOTAFTER This is the same logic as ALAP. We simply take the OriginalScheduleTime instead of the Channel CutOff , adjusted with the lead time. 4.2.4. Relationship between Default Schedule and MetaSchedule The following table provides the cross reference between the channel DefaultSchedules and the transaction MetaSchedules , with the indication of where the result type is kept. In this table: • S indicates a sequence stored into CalculatedPriority . • T indicates a time stored in CalculatedScheduleTime . • Channel keywords are placed vertically. • Transactions MetaSchedules are placed horizontally. 23 Configuring the Payment Flow Control Module ASAP ALAP FIXED NOTBEFORE NOTAFTER FIFO S, fifo T, ALAP T fixed T, NB T, NA LIFO S, lifo T, ALAP T fixed T, NB T, NA PRIORITY-AMOUNT S, P-A T, ALAP T fixed T, NB T, NA PRIORITY+AMOUNT S, P+A T, ALAP T fixed T, NB T, NA FIXED T, Fixed T, ALAP T fixed T, NB T, NA NOTAFTER T, NA T, ALAP T fixed T, NB T, NA 4.2.5. Main Output Variables Computed by LMS Used in Scheduling The following are the main output variables used in scheduling: • ComputedPriority1-3 (Transactions) OUTPUT Results of the sequencing functions are stored here. We have several occurrences of the field, since we can have different priority schemes depending upon the time of day. All schemes are systematically computed at the same time. The Release Handler will base its selection on different occurrences, depending upon the time of day. • ComputedScheduleTime1-3 (Transactions) OUTPUT Results of the timing functions are stored here. We have several occurrences of the field, since we can have different priority schemes, depending upon the time of day. • CutOff (Transactions) OUTPUT This is the effective cutoff time for the transaction. This is determined based upon the cut of times defined in the cutoffs section of the Channel record. The cutoff used depends on the type of the payment (Customer Payment, Bank to Bank payment) as defined on the transaction. 4.3. Release Processing The following section describes release processing, including the Release Handler components, transaction selection, cutoff processing, status codes, and limit processing. 4.3.1. Release Processing Overview When a transaction is received by the system through the preprocessor, its state in the payment workflow is defined by its type and status. In order to be released, a payment also needs to have a Channel allocated to it. In the Workflow States table, LMS defines that a number of combinations of Type, Status, and Channel are suitable for automated release. The transactions in automated release states are filtered by the underlying Streaming Platform, published via MQ to a message queue and then onto a technical table called TransactionsReleaseWritable (TRW). This table will contain only transactions that can be released automatically. It is also used to control concurrency within the system. 24 Configuring the Payment Flow Control Module The release process itself will be logically made up of two types of components: 1. The Dispatcher: This component presents the transactions to the Release Handler in the computed order. The Dispatcher subscribes to the TransactionsReleaseWritable table and marks records on this table to indicate that the Transaction has been passed to a Release Handler. 2. The Release Handler: This components validates that the transactions can be released by invoking the limit checks, potentially generate alerts messages, and change the transaction state to “released” by creating a new event and posting it to the MQ. The new type status of the released transaction is determined by consulting the WorkflowTransitions table. There are two subtypes of Release Handlers running under the Release Handler process: • One type of Release Handler deals with priority-based releases. • The other type of Release Handler deals with releases scheduled by time. For each Channel, there are two Release Handlers. Release Handler processing is driven by release rules, which are part of the Release Handler configuration. Depending on the release rules established at the bank, payments that fail release can be either: • Left in place in the queue to be retried later. -or• Moved to a Held queue. A payment transaction can move to a releasable state after an event is received by the preprocessor. The preprocessor updates the transaction [1]. If the resulting type/status/channel combination on the resulting transaction update is defined in the workflow states as being subject to auto-release, engines rules are used to create a target table (a view) that only contains the list of transactions ready for automatic release processing [2]. For concurrency-control considerations, we want to be able to directly update records contained in this table, so we use the engine to publish the transaction to the MQ, and then use a duplicator process to create the record in a source engine table, TRW [3]. When a payment transaction is releasable by LMS, it will be in a workflow state in which a TRW record is associated with the transaction. Concurrency control is required to avoid a payment being sent out twice. Such a thing might happen, for example, when a user reroutes a payment precisely at the moment the payment is being released to another Channel. In general, this could occur whenever a payment could be processed by two different release handlers. The TRW record will eventually be read by the Dispatcher executing a SQL query [4]. The Dispatcher will mark the TRW record [5] so that it is not selected a second time while it is being processed. The Dispatcher will pass the transaction to the Release Handler responsible for the Channel and type of release [6]. The Release Handler will then execute its release rules [7]. If the release checks are successful, then the Release Handler will create an outbound message [8] and will generate a new Event [9] to update the transaction status to a released state. Both will be queued to the MQ and controlled under the same MQ syncpoint. The Event will be picked up by the preprocessor; the outbound message will be picked up by the outbound formatter or possibly by the Alerter. When the transaction is updated, then its workflow state should not be susceptible to be processed automatically, thus deleting the Transaction Release record [10]. The engine publishing will generate a delete operation, which after some controls described 25 Configuring the Payment Flow Control Module later in this document, is applied to the TRW record [11]. The cycle is then complete. If the payment was not released, then it can be left in the same workflow state, so that the release operation can be retried later. In this case, the Release Handler must unmark the TRW record, so it can be selected again by the Dispatcher [12]. If the payment is moved to a “hold” state requiring a manual intervention, then the Release Handler will create an event with a HOLD status that is not processed automatically by LMS. Once the transaction is updated, the TRW will be deleted, following the same processing as for a release [9], [10], [11]. The manual release process will be done through a status update of a transaction. The transaction will be moved to a new workflow state that can be processed automatically, but different rules will be selected by the Release Handler. Typically, these rules would force release regardless of the limit check. 4.3.2. Release Handler Components The Release Handler (RH) mechanism consists of the following logical modules: • Dispatcher • Releasor • Limit Processing In order to work, Release Handler (RH) needs a running instance of the Streaming Platform with static data initialized. 4.3.2.1. Release Handler Component - Dispatcher The Dispatcher acts as a controlling module to the Release Handler. It passes transactions eligible for release to its clients, which are Release Handlers that have subscribed to it. The Dispatcher generally ensures that a transaction cannot be dispatched twice at the same time to different Release Handlers. The Dispatcher is a single Java process to which multiple Releasors can connect. It contains the duplicator logic, which duplicates records from a TransactionReleasable (TR) to a TransactionReleaseWritable (TRW) table. For each Releasor connected to it, the Dispatcher establishes an RH context. An RH context is specified by the following items: • Contest Number (1, 2, 3, etc.) • Channel ID. • Release type (Timed or Scheduled). The Dispatcher also includes a Scheduler, which is used internally to trigger Channel-open and Channelclose events. 4.3.2.2. Release Handler Component - Releasor When a Releasor process begins, it registers with the Dispatcher for a Channel and a release type. It can optionally supply an operating date. Each transaction received from the Dispatcher is made available to a python script. The python script can examine all transaction attributes and perform the following actions: 26 Configuring the Payment Flow Control Module • Attempt Release – In this action, the Releasor formats a limit check request to the Limit Checker. • If the limit check request passes, the status field of the transaction is set to RL (Released), the Limit Check Type is set to 1 , and the XML-formatted record is queued to MQ, destined for the preprocessor. • If the limit check request fails, the status field of the transaction is set to HD (Held) and the data is queued to the preprocessor. This is not default behavior, but is configured in the script. The script defines that external queuing is possible/required. The definition of the queues is in Release.properties . • Force Release – This action works like the action above, except that the request to Limit Checker is a force release, and the Limit Check Type is set to 2 . A force release always succeeds. • Change Status – In this action, the transaction data is queued to the preprocessor with a limit check. The script can control the values to queue by setting the appropriate fields within the transaction record before calling Change Status. This is temporary, since later, the transaction fields will be made non-modifiable. 4.3.3. Transaction Selection Transactions are selected by the Dispatcher using a parameterized SQL query provided in the Release.properties configuration file. The query is made against the TRW table. The major selection criteria for a transaction is configurable in the SQL statement. Importantly, the Dispatcher performs one additional filtering in code: It determines if a transaction is past its cutoff time. (This is temporary, until time-component-comparison support is supported in SQL). To do so, the cutoff time is compared to the system time. Thus, it is important. The SQL query should be coded so that only transactions that are candidates to be released on the operating date are selected; cutoff checking is done based solely on the times. 4.3.3.1. Query Parameters The following are query parameters that are currently implemented: Query Parameter Definition $CHANNEL Replaced by the Channel ID that an instance of the Dispatcher is working with. $OPERDATE The operation date as determined either from Channels.Current Date or passed in by a Releasor. Currently, an RH instance needs to be restarted to change the OPERDATE. Later, this will be driven from the Channels table. The format is yyyy-MM-dd. $NOWDATETIME Current system date time, in the format yyyy-MM-dd.hh:mm:ss, that is suitable for SQL datetime comparisons. No TZ or DST adjustments are made. $NOWTIME Current system time. $NOWDATE Current system date. $UTCDATETIME Current UTC date time in the format yyyy-MM-dd hh:mm:ss. 27 Configuring the Payment Flow Control Module $UTCTIME Current UTC time. $UTCDATE Current UTC date. 4.3.4. Cut-Off Processing Transactions for a channel are released only when that channel is open. Although a particular transaction is filtered out using its cut-off times, the overall channel state is determined using the following fields: Channel.WindowStart and Channel.WindowEnd . The Dispatcher assumes that the times on these two fields are local times (local times in terms of the host machine), and corresponding adjustments are always made. Cutoff processing is intended to filter transactions coming into the system after a certain time, and is able to integrate these into the positions following a manual intervention. The system defines three cut-off times. The cut-off times are intended for: 1. Customer payments 2. Interbank payments 3. Adjustments The system defines these values based on the cut-off times established on the transaction Channel and the payment category (for example, Customer, Interbank, or Adjustment). Data feeds into LMS need to supply the information that the transaction is potentially subject to adjustment, and will allow the system to put it into a suitable workflow. Furthermore, the feeds will provide some categorization that allows LMS to choose the cutoff time to be applied. For example, the SWIFT message type can be used to distinguish between customers and bank-to-bank payments. This allows LMS to allocate a payment category to the movement. This categorization is a logical one. For example, we would expect the category to be set via the Adapters. The following logic will then be applied: 1. Map the incoming event and produce the transaction record. Use the data from the feed to map the payment category into the event. Possible results can be one of the following: Transactions will not be released without a Channel. • Customer • Bank-to-bank • Adjustment • 2. Once the transaction record has been updated or created from this event, then the type and status of the transaction are checked against the Types Status table to determine if this particular state is subject to "late handling." Late handling indicates that the transaction is in its current state and has not yet been executed. 28 Configuring the Payment Flow Control Module 3. LMS computes the cutoff time in its processing model. For example, if the Channel is known, LMS uses the channel cutoff or the currency cutoff. The current computation is then enhanced to take into account the "previous day adjustment" for the cutoff time. The currency for the movement determines which calendar to use. 4. LMS then tests if the transaction processed time is greater than the relevant cutoff time. If this is the case, the transaction is marked as late. If the transaction is marked as late, it is not included in the positions. To integrate the movement into the position, perform one of the following actions: • Manually update the transaction to a workflow state not subject to late handling. -or• Use the Bulk Reschedule to select a group of transactions and perform an update, move the transactions to a workflow state, adjust the date on the transaction, and set the rescheduled flag. 4.3.4.1. Determining if a Transaction is Late The transaction will carry a payment category indicating whether it is a Customer, Interbank or Adjustment transaction. The payment category is used to determine which Channel cutoff applies to the transaction. Given the transaction value date, LMS computes the cut-off time for the transaction (the Transactions.CutOff field). When the current time is greater than Transactions.CutOff , the Transaction is late and is not selected by the Dispatcher. NOTE: This is different from the Late flag on the Transactions, which indicates that the Transaction was late at a point in time. 4.3.4.2. Determining if a Channel is Open A Channel is open when it will accept messages. The Channel close time is the maximum of cutoff times. The Channel open time is WindowStart. 1. First, the Channel state ( Channel.State ) must be open, as opposed to blocked or closed. Any state besides open means that the Channel is not available. 2. Next, the current system date-time must be between the Channel open date-time and the Transaction cutoff date-time for the date we are processing on the Channel ( Channels.CurrentDate ). If the Channel open date-time is greater than the Channel close date-time, then the Channel open date time is adjusted to the previous day. This adjustment to the previous day must take place before adjustment to UTC. The start-time can be greater than the end-time, when for example, the Channel closes at 18:00 and reopens for the next day at 21:00. Example 1: Simple Case The following is an example of a simple case. 2005-11-16 falls on a Wednesday. Column Name Value Channels.WindowStart 08:00 29 Comment Configuring the Payment Flow Control Module Column Name Value Comment Channels.CurrentDate 2005-11-16 Channels.CutoffTimeInterbankPayments 16:00 Channels.InterbankCutoffAdjustment 0 No adjustment Channel.Location<->Locations.TimeZone Europe/London Lookup join to the Locations table. System date and time 2005-11-16T10:00:00 Transactions.ValueDate 2005-11-16 Transactions.PaymentType 2 Transactions.CutOff 2005-11-16T16:00:00 Computed in the model. An InterBank payment(202). 1. If we are in the United Kingdom during winter, we are on UTC (Coordinated Universal Time). There are no time-zone adjustments to consider. 2. Since the Transaction is an Interbank payment, the cutoff time used is the Interbank cutoff. It is applied to the ValueDate. 3. The Channel opening date-time, which is a programmatic field rather than a column, is computed based on the Channel current date and WindowStart . In this example, that would be equal to 2005-11-16T08:00:00 . 4. Since we have Transactions.CutOff > System Date and Time > Channel Opening Time , and value date is equal to the Channel current date, the transaction can be released. Example 2: One-Day Notice Required The following is a real-life example, where the SEK correspondent of the bank requires that payments orders are sent to him by 12:00 on the previous business day. In this example, 2005-11-16 falls on a Wednesday. Column Name Value Channels.WindowStart 08:00 Channels.CurrentDate 2005-11-16 Channels.CutoffTimeInterbankPayments 12:00 Channels.InterbankCutoffAdjustment -1 30 Comment Adjust to previous business day. Configuring the Payment Flow Control Module Column Name Value Comment Channel.Location<->Locations.TimeZone Europe/Stockholm Lookup join to the Locations table. System date and time 2005-11-16T10:00:00 (UTC) Transactions.ValueDate 2005-11-16 Transactions.PaymentType 2 An InterBank payment(202). Transactions.CutOff 2005-11-15T11:00:00 Computed in the model. 1. As the Transaction is an Interbank payment, the cutoff time used is the Interbank cutoff. 2. The value date is first adjusted to the previous business day. 3. In this case, the location references Europe/Stockholm, and the adjusted date is outside of the daylight saving period, the time needs to be adjusted to UTC by one hour. 4. The Channel opening date time, which is a programmatic field rather than a column, is computed based on the Channel current date, the applicable Interbank cut off adjustment, and WindowStart and should be equal at this point to 2005-11-15T07:00:00 . 5. As we have Transactions.CutOff < System Date and Time , the transaction cannot be released, since we are past its cutoff point. Column Name Value Channels.WindowStart 08:00 Channels.CurrentDate 2005-11-17 Channels.CutoffTimeInterbankPayments 12:00 Channels.InterbankCutoffAdjustment -1 adjust to previous business day. Channel.Location<->Locations.TimeZone Europe/Stockholm Lookup join to the Locations table. System date and time 2005-11-16T10:00:00 (UTC) Transactions.ValueDate 2005-11-17 Transactions.PaymentType 2 31 Comment An InterBank payment(202). Configuring the Payment Flow Control Module Column Name Value Comment Transactions.CutOff 2005-11-16T11:00:00 Computed in the model. 1. The Channel opening date time, which is a programmatic field rather than a column, is computed based on the channel current date, the applicable Interbank cutoff adjustment, and WindowStart . In this example, it should be equal to 2005-11-16T07:00:00 . 2. As we have Transactions.CutOff > System Date and Time > Channel Opening Time , and value date is equal to the Channel current date, the transaction can be released. Example 3: Fedwire In the case of Fedwire, the Channel closes in the evening and opens for the next day before midnight. The Federal Reserve Bank's funds transfer business day begins at 9:00 p.m. Eastern Time (ET) on the preceding calendar day and ends at 6:30 p.m. ET, regardless of the Reserve Bank’s geographic location or time zone. For example, on a Sunday, the Fedwire Funds Service will open at 9:00 p.m. ET with a cycle date of Monday, although transfers sent from 9:00 p.m. to midnight ET on Sunday will settle in real time on Sunday. In this example, 2005-11-16 falls on a Wednesday. Column Name Value Comment Channels.WindowStart 21:00 Channels.CurrentDate 2005-11-16 Channels.CutoffTimeInterbankPayments 18:00 Channels.InterbankCutoffAdjustment 0 No adjustment. Channel.Location<->Locations.TimeZone America/New York Lookup join to the Locations table. System date and time 2005-11-16T10:00:00 (UTC) Transactions.ValueDate 2005-11-16 Transactions.PaymentType 2 An InterBank payment(202). Transactions.CutOff 2005-11-16T23:00:00 Computed in the model. 1. The Channel opening date time. a programmatic field rather than a column, is computed based on the channel current date and WindowStart , which, in this example, would be equal to 2005-11-16T01:00:00 . The opening date is first adjusted to the previous day, on the basis that the default calculation is Channel current date + window start = 2005-11-16T21:00:00( America/New 32 Configuring the Payment Flow Control Module York) -> 2005-11-17T01:00:00 UTC than the max of the cut-offs : 2005-11-15T21:00:00(America/New York) . This time is then adjusted back to UTC, giving 2005-11-16T01:00:00 . This should be done in this order to cover the switch to summer time. 2. Since we have Transactions.CutOff > System Date and Time > Channel Opening Time , and value date is equal to the Channel current date, the transaction can be released. Example 4: Extended Opening Hours In this example, we imagine that the Channel opening hours are extended past midnight. We imagine that, for whatever reason, business activity was severely disrupted on a given day, and the Central Bank has decided to allow settlement banks to execute payments until 1:00 a.m. on the following day. The users must update the Channel to reflect these exceptional circumstances. In this case, the update will be to change the applicable cutoff times. The cutoff times will also need to carry an adjustment into the next business day. We use business days rather than calendar days since we only support adjustments expressed in business days. Column Name Value Comment Channels.WindowStart 08:00 Channels.CurrentDate 2005-11-16 Channels.CutoffTimeInterbankPayments 03:00 Channels.InterbankCutoffAdjustment +1 Adjust to next (business) day. Channel.Location<->Locations.TimeZone Europe/London Lookup join to the Locations table. System date and time 2005-11-17T01:30:00 Transactions.ValueDate 2005-11-16 Transactions.PaymentType 2 Transactions.CutOff 2005-11-17T03:00:00 Computed in the model. An InterBank payment(202). 1. The Channel opening date time is computed based on the channel current date and WindowStart, and in this example, would be equal to 2005-11-16T08:00:00 . 2. As we have Transactions.CutOff > System Date and Time > Channel Opening Time , and the value date is equal to the Channel current date, the Transaction can be released. NOTE: If you look at the Fedwire example in the section above, the Channel WindowStart should also be updated. For example, it should be updated to 00:01 , if the extension takes place before the normal open of the Channel to the next day. 4.3.5. Status Codes 33 Configuring the Payment Flow Control Module The Dispatched field on the TRW record is used by Release Handler to mark various states the transaction is in during the release processing cycle. The return code is a combination of the Limit Checker result and script processing. The script has the option to set the return code explicitly. If it does not, Release Handler computes it as follows: 1. If a record is queued onto MQ, the record will not be re-queried. 2. If script processing does not result in queueing to MQ, the record will be subject to re-query. 3. The result of the limit check is always placed in the lowest byte, regardless of whether the record will be re-queried. The Dispatched field is a int32_t field (in other words, 4 bytes). The four bytes are used as follows: | B3 | B2 | B1 | B0 | • Byte B3 – This is used by the Release Manager to indicate why a transaction has not been released as configured in the release.py script (python script). • Byte B2 – This is marked when a processing error occurs. • Byte B1 – This is for marking the stage that the transaction is in during processing. • Byte B0 – This is the lowest byte. It is for limit check return codes. Limit Checker return codes are bitmapped values, with each bit representing the pass or failure of a limit. The bit assignments are as follows: Value Bit Assignment BILATERAL bit 0 (0x01) GROUP bit 1 (0x02) SUBCHANNEL bit 2 (0x04) MULTILATERAL bit 3 (0x08) OVERALL bit 4 (0x10) A value of 0x10 in the lowest byte means the overall limit failed. A value of 0x03 means both bilateral and group limits failed. Example: The Processing Stage Byte 1 is used by Release Handler to mark the processing stage. For example: • If 0x00 – This means that the record will be picked up on query. • If 0x01 – This means that the record is currently within Release Handler being processed. 34 Configuring the Payment Flow Control Module • If 0x02 – This means that the record has been processed and will not be looked at unless updated externally. • If 0x04 – This means that the record encountered an non-retryable error (for example, the workflow state is not being found). If Byte 2 is not zero, Release Handler encountered a processing error. Example: How the Value of the Dispatched Field may be Handled The following is an example of how the value of the Dispatched field may be handled: Value Definition If dispatched = 0 The record has not been processed yet. If dispatched = 256 The record is currently being processed. If dispatched > 0 and < 256 The record has been processed. The value in byte 0 is the limit check result. It will be re-queried. If dispatched >= 512 The record has been processed. The value in byte 0 is the limit check result. It will not be re-queried. If dispatched >= 1024 The record encountered a non-retryableerror. If dispatched >= 65536 The record encountered a processing error. 4.3.6. Limits Processing Limit Processing within the PFC module is an inherent part of the release process. It checks that sufficient cash, collateral, and limit availability exists to process the payment amount without causing the limit to go into excess. The limit checker determines whether a transaction to be released is constrained by any limits defined in LMS. LMS can process four types of limits as part of the release process: 1. Bilateral Limits – A limit on the net debit position of the counterparty bank in payment transactions at a Channel. For example, payments with CITIBANK, London at CHAPS. 2. Group Limits – A limit on the net debit position of a group of counterparty banks in payment transactions at a Channel. For example, CITIBANK Group (including CITIBANK, London; CITIBANK, New York; and CITIBANK, Tokyo) at CHIPS. 3. Multilateral Limits – A limit on the net debit position on the counterparty banks for which no Bilateral or Group Limits have been defined. In effect, an everyone else limit at a Channel. For example, a Multilateral limit at TARGET2. 4. Overall Limits – Effectively, the Overdraft limit to which the bank is subject at a Channel. For example, the overall limit at TARGET2. 35 Configuring the Payment Flow Control Module To determine the payment counterparty for limits purposes ( LimitsDefinition.Entity ), the limit checker looks for a non-null Party ID in the transaction in the following fields: 1. First, the Transaction Correspondent field is checked. 2. Next, if the Transaction Correspondent field is null, the Transaction Beneficiary Bank Field is checked. 3. If both the Transaction Correspondent field and the Transaction Beneficiary Bank fields are null, the Transaction Counterparty field is checked. 4. If all of the above fields are null, the system assumes that the Bilateral and Group Limits do not need to be checked for the transaction. In this case, only Multilateral and Overall Limits will be checked. The PFC module allows the capture of Channel Cross References to determine the Parties for limitchecking. The Party ID in the transaction record being processed is compared to the External IDs in the Cross Reference table. If a match is found, the related Internal ID from the Cross Reference table is used for limit look up (rather than the Party ID from the transaction). Having found any applicable limits for the transaction, the limit checker determines if there is sufficient limit availability to release the payment. • If limit check is successful, it will be scheduled for release and the limit availability is reduced by the payment amount. • If limit check is unsuccessful, the payment can be placed into a pending state (HD (or Held) in the base delivery) and the limit availability remains unchanged. Incoming receipts of funds are sent to the limit check process to update the limit utilization with the amount of cash received at the channel. Utilization for all four limit types is decreased by the amount of incoming funds as appropriate. The Limits Definition has keys of Channel ID, Entity (from Transaction or Party), and Limit Type. The keys must match up with the Transactional data for limits to work. 4.3.6.1. Limit Utilization Criteria To be included in the Limits Utilization, a transaction must meet the following criteria: • Preprocessor Transactions.TS_Available must not equal +0 or -0 . • LimitsDefinition.LimitType must resolve to one of the following: • 1 - Bilateral • 2 - Collective by Group • 4 - Multilateral • 5 - Collective Overall • LimitsDefinition.ChannelId tions.ChannelId must 36 match PreprocessorTransac- Configuring the Payment Flow Control Module • For LimitType1 (Bilateral), LimitsDefinition.Entity must match: • PreprocessorTransactions.Correspondent • or • PreprocessorTransactions.BeneficiaryBank • or • PreprocessorTransactions.Counterparty • or • A lookup from Cross Reference to an Internal ID In addition, for Internal ID lookup to succeed, the CrossReference.CrossReferenceType (for a Transaction it is taken from the Channel.CrossReferenceType ) must match the value on the Limits Definition. • For LimitType2 (Collective By Group), LimitsDefinition.Entity must match the lookup of Parties.GroupId using Parties.Identifier from one of the following: • PreprocessorTransactions.Correspondent • or • PreprocessorTransactions.BeneficiaryBank • or • PreprocessorTransactions.Counterparty • or • A lookup from LimitsCrossReference to an InternalId • For LimitTypes4 (Multilateral), the LimitsDefinition.Entity must match N/A . • For LimitTypes5 (Overall), the LimitsDefinition.Entity must match N/A . 4.4. PFC Configuration The following section describes how to start Release Handler, work with the various configuration files, and perform the PFC configuration. It also discusses Limits configuration. 4.4.1. Release Handler Configuration Diagram The Release Handler automatically processes Expected Payments transactions (EP/EX) through the Limit Checking process to the release. 4.4.2. Starting Release Handler The start scripts for PFC are in the lms/control directory. The following files are used to generate the appropriate sections in the startup scripts: • pfcfunctions 37 Configuring the Payment Flow Control Module • rhcontroller.sh The contents of these files are normally imported into the startup scripts when the environment is set up using updateconfig.sh found in the root of the environment. • To start Release Handler: On start-up, perform the following steps: 1. Start the Dispatcher. The Dispatcher has a single optional command line argument (this is, its configuration file). By default, it picks up lms/ conf/business/release.properties. The Dispatcher starts the duplicator thread, which subscribes to the TransactionRelease stream and publishes all updates to the TransactionReleaseWritable (TRW) stream. 2. Start Limit Checker. Limit Checker has one mandatory command line argument (the value date for which it will check limits). Limit Checker reads in the Parties table and waits for a connection from Releasor. 3. Start the Releasor threads. Each Releasor is a processing thread A Releasor has two mandatory command-line arguments: • The Channel for which it should process records. • A flag indicating whether it is processing Timed payments or Scheduled payments. A Releasor connects with the Limit Checker and the Dispatcher. 4. For each connection, the Limit Checker spawns a service thread. It reads the LimitDefinition table for the connected channel and waits for the limit requests. 5. For each connection, the Dispatcher establishes an RH context. This context is categorized by: • The channel name. • The release type (either Timed or Scheduled). • The SQL query used to retrieve transactions. By default, the Dispatcher determines the operating date for the context from the Channels.CurrentDate field. This can be overridden by providing the date to the Releasor when it starts up. 6. Within the context, the Dispatcher examines the Channels record for the Channel to establish the open and close times. It uses the WindowStart and WindowEnd fields to do so. The Dispatcher assumes that the times on these two fields are local times. For example, if WindowStart is xxxx-xx-xx 08:00:00, the channel opens at 08:00:00 local machine time. 7. As long as the channel remains open, the Dispatcher polls the TRW stream for transactions to release, using the SQL query specified for the channel and release type in release.properties. There are a number of predefined variables that can be used to build the query (details follow). Each selected transaction is passed to the Releasor process. 8. The Releasor passes the transaction to a python script. The script can examine the transaction fields and take a number of actions (details follow). 38 Configuring the Payment Flow Control Module 4.4.3. PFC Configuration Files Configuration files determine the functionality of the PFC module. The files are: 1. rh-channels-contexts-list file – located in lms/conf/business. 2. release.properties file – located in lms/conf/business. 3. release.py file - located in lms/conf/business. 4.4.3.1. Configuring the rh-channels-contexts-list File The rh-channels-contexts-list file determines which channels are subject to flow control and limit checking within LMS. There MUST be entries for each channel that is to be subject to LMS flow control. The example below illustrates the required entries for two channels, CHAPS, T2RTGSARGET2 and FEDWIRE: Channel1 Channel2 Channel3 Channel4 Channel5 Channel6 = = = = = = CHAPS TIMED CHAPS SCHEDULED T2RTGS TIMED T2RTGS SCHEDULED FEDWIRE TIMED FEDWIRE SCHEDULED Note that the rh-channels-contexts-list file MUST have the required entries for each channel subject to PFC processing. 4.4.3.2. Configuring the release.properties File The release.properties file contains the technical configuration for the Release Handler. This file includes: • Basic Release Handler Config • Platform Access config • MQ config • Location of the release.py(release rules) file • Model-related setting • Release context and SQL query settings The following is an example of the content of the base release.properties file. The file is largely self-documenting. # # # # # # # --------------------------------------------------------------------SAP Liquidity Management for Banking Copyright (c) 2005, 2017 SAP SE or an SAP affiliate company. All rights reserved. Please see http://www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices. 39 Configuring the Payment Flow Control Module # --------------------------------------------------------------------# Release Handler Configuration # --------------------------------------------------------------------# --------------------------------------------------------------------# Generic Release Handler Settings # --------------------------------------------------------------------# Interval (in seconds) ReleaseHandler will wait before re-querying TRW # if all payments were rejected by Limit Checker. releasehandler.limitRetryInterval = 5 # Scripting to use. Values: Jython (Python) , Rhino (Javascript) releasehandler.scriptEngine = Jython # Flag to indicate whether raw message should be included in the # transaction data. # - true (include raw message) # - false (exclude raw message) releasehandler.rawMessageInTransaction = false # --------------------------------------------------------------------# Release Handler Output Configuration # --------------------------------------------------------------------# JMS provider configuration releasehandler.output.destination.Preprocessor = QUEUE_LMS_EVENTS releasehandler.output.destination.External = QUEUE_LMS_EXTERNAL releasehandler.output.destination.Alert = QUEUE_LMS_ALERTS # FileSink configuration (for testing and debugging only) #releasehandler.output.filename.Preprocessor = /lms/home/tst321de/lms_6.2.6-10052017/lms_services/lms/output/rh-events.xml #releasehandler.output.filename.External = /lms/home/tst321de/lms_6.2.6-10052017/lms_services/lms/output/rh-external-events.xml #releasehandler.output.filename.Alert = /lms/home/tst321de/lms_6.2.6-10052017/lms_services/lms/output/rh-alerts.xml # --------------------------------------------------------------------# Release Context Configuration # --------------------------------------------------------------------# Default script file for a release context releasehandler.scriptFile = /lms/home/tst321de/lms_6.2.6-10052017/lms_services/lms/conf/business/release.py # Default file containing the release contexts list releasehandler.contextListFile = /lms/home/tst321de/lms_6.2.6-10052017/lms_services/lms/conf/business/rh-channels-contexts-list # --------------------------------------------------------------------# Release Context Configuration - Model-related Settings # --------------------------------------------------------------------# - PreprocessorFields ---# Fields to be sent to preprocessor. Comma separated list of fields to # be picked up from the Transactions record. Field remapping is # supported by specifying TXField:EventField. In addition to these, # ReleaseHandler will fill in... # - UniqueId Generated unique id string # - AdapterStatus Calculated using workflow transitions and script # parameters # - Status Calculated using workflow transitions and script # parameters # - LimitCheckType 1 if script attempts limit, 2 if script forces limit # - LockId Generated string value releasehandler.preprocessorFields = Id:CurrentId:OriginalId, RawMessage:RawMessage # - PartyFieldName ----# Field on the transaction record that will contain the destination # party for the payment (defaults to PartyId) releasehandler.partyFieldName = PartyId # # # # # # # # # # --------------------------------------------------------------------Release Context Configuration - Customizable Settings --------------------------------------------------------------------The settings below can be customized for a release context. Each release context is identified by a unique string which needs to be specified using the controller to start up that particular group. Setting that can be customized are - SQLQuery - ScriptFile - ChannelTimezone 40 Configuring the Payment Flow Control Module # # # # # # # # # # # # # # # # # # # # - MQ.Queue.Preprocessor - MQ.Queue.Alert SQL queries can include replaceable parameters. Currently supported params are: $CHANNEL Replaced by the ChannelId an instance is working with $OPERDATE The operation date as determined either from Channels.CurrentDate or passed in by a releasor. Currently an RH instance will need to be restarted to change the OPERDATE. Later this will be driven from the Channels table. Format - 'yyyy-MM-dd' $NOWDATETIME Current system date time in the format 'yyyy-MM-dd hh:mm:ss' suitable for SQL datetime comparisons. No TZ or DST adjustments are made $NOWTIME Current system time $NOWDATE: Current system date $UTCDATETIME Current UTC date time in the format 'yyyy-MM-dd hh:mm:ss' $UTCTIME Current UTC time $UTCDATE Current UTC date ### START_ORACLE_ONLY # Default SQL query for a ReleaseContext. See below for details on # available variables releasehandler.SQLQuery = SELECT * FROM ( SELECT * FROM V_TransactionRelease \ WHERE Dispatched < 256 \ AND ChannelId = '$(CHANNEL)' \ AND MetaSchedule = 'ASAP' \ AND HoldScheduled <> 1 \ AND Conditional = 0 \ ORDER BY ComputedPriority1 ) \ WHERE rownum <= 10 # The timed query will select everything which is scheduled by time # (everything where the MetaSchedule is not ASAP). releasehandler.TIMED.SQLQuery0 = SELECT * FROM V_TransactionRelease \ WHERE Dispatched < 256 \ AND ChannelId = '$(CHANNEL)' \ AND MetaSchedule <> 'ASAP' \ AND Conditional = 0 \ AND AdapterStatus <> 'RM' \ AND ValueDateTime = TO_TIMESTAMP ('$(OPERDATE) 00:00:00'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND Cutoff > TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND (ComputedScheduleTime1 < TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS')) AND rownum <= 10 releasehandler.TIMED.SQLQuery1 = SELECT * FROM V_TransactionRelease \ WHERE Dispatched < 256 \ AND ChannelId = '$(CHANNEL)' \ AND MetaSchedule <> 'ASAP' \ AND Conditional = 0 \ AND AdapterStatus <> 'RM' \ AND ValueDateTime = TO_TIMESTAMP ('$(OPERDATE) 00:00:00'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND Cutoff > TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND (ComputedScheduleTime2 < TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS')) AND rownum <= 10 releasehandler.TIMED.SQLQuery2 = SELECT * FROM V_TransactionRelease \ WHERE Dispatched < 256 \ AND ChannelId = '$(CHANNEL)' \ AND MetaSchedule <> 'ASAP' \ AND Conditional = 0 \ AND AdapterStatus <> 'RM' \ AND ValueDateTime = TO_TIMESTAMP ('$(OPERDATE) 00:00:00'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND Cutoff > TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND (ComputedScheduleTime3 < TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS')) AND rownum <= 10 releasehandler.SCHEDULED.SQLQuery0 = SELECT * FROM ( SELECT * FROM V_TransactionRelease \ WHERE Dispatched < 256 \ 41 Configuring the Payment Flow Control Module AND ChannelId = '$(CHANNEL)' \ AND MetaSchedule = 'ASAP' \ AND HoldScheduled <> 1 \ AND Conditional = 0 \ AND ValueDateTime = TO_TIMESTAMP ('$(OPERDATE) 00:00:00'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND Cutoff > TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS') \ ORDER BY \ (CASE WHEN AdapterStatus='RM' \ THEN ComputedPriority1 + 32535259200 \ ELSE ComputedPriority1 END) DESC ) \ WHERE rownum <= 10 releasehandler.SCHEDULED.SQLQuery1 = SELECT * FROM ( SELECT * FROM V_TransactionRelease \ WHERE Dispatched < 256 \ AND ChannelId = '$(CHANNEL)' \ AND MetaSchedule = 'ASAP' \ AND HoldScheduled <> 1 \ AND Conditional = 0 \ AND ValueDateTime = TO_TIMESTAMP ('$(OPERDATE) 00:00:00'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND Cutoff > TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS') \ ORDER BY \ (CASE WHEN AdapterStatus='RM' \ THEN ComputedPriority2 + 32535259200 \ ELSE ComputedPriority2 END) DESC ) \ WHERE rownum <= 10 releasehandler.SCHEDULED.SQLQuery2 = SELECT * FROM ( SELECT * FROM V_TransactionRelease \ WHERE Dispatched < 256 \ AND ChannelId = '$(CHANNEL)' \ AND MetaSchedule = 'ASAP' \ AND HoldScheduled <> 1 \ AND Conditional = 0 \ AND ValueDateTime = TO_TIMESTAMP ('$(OPERDATE) 00:00:00'\\, 'YYYY-MM-DD HH24:MI:SS') \ AND Cutoff > TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS') \ ORDER BY \ (CASE WHEN AdapterStatus='RM' \ THEN ComputedPriority3 + 32535259200 \ ELSE ComputedPriority3 END) DESC ) \ WHERE rownum <= 10 ### END_ORACLE_ONLY Note In case you want to escape a character, you need to use two slash \\. e.g. in below line \\ is used to escape "," after '$(UTCDATETIME)'. TO_TIMESTAMP ('$(UTCDATETIME)'\\, 'YYYY-MM-DD HH24:MI:SS') 4.4.3.3. Configuring the release-py File The release.py file is a Python script containing rules for the Releasor. The rules determine how to handle manual releases, queuing to the outbound formatter, and Alert processing. The script is executed once for each payment being evaluated for release. Each payment is considered independently of the others. The following rules are allowed: • Testing of transaction characteristics. • Conditionally generating outbound messages. 42 Configuring the Payment Flow Control Module • Conditionally generating update events carrying a change of workflow state. • Conditionally generating alert messages. • Choosing between the different types of limit checks (forced or not). The release.py File Data The data is available to the script at run time. This data includes: • The transaction object being evaluated for release. • The name of the Release Handler on behalf of which the script is executing (for example, CHAPS_MANUAL). This object cannot be modified by the script. Logically, this transaction object contains the union of all the fields from the Transaction, the Event, and the alert structures. The example below illustrates the base delivery release.py file: # # Release Version/Tag: $Name: $ # Additional Info: $Id: release.py.template,v 1.4 2006/09/27 20:37:53 cbiswa Exp $ # from com.aleri.lms.alerts import AlerterMessage; # if the item is picked up from the Manual release state we will force the release. if (rh.transaction["AdapterStatus"]=="RM"): # call limit check with force option rh.forceRelease("RELEASE",1); alert=AlerterMessage(); alert.category="Manual release for " +"%d"%rh.transaction["OriginalAmount"]+ " "+rh.transaction["Currency"]; alert.cause="Manual Action"; alert.reference=rh.transaction["CurrentId"]; alert.to="[email protected]"; # rh.sendAlert(alert); else : #do a normal limit check if (not rh.attemptRelease("RELEASE",1)): # if it fails above a certain amount move to the hold queue. # Don't send anything to the outbound formatter # We send an alert that the payment is held if (rh.transaction["AdapterStatus"]!="HD" and rh.transaction["OriginalAmount"]>1000000.0):rh.changeStatus("HOLD",0); alert=AlerterMessage(); alert.category="High value payment not released - check hold queue" ; alert.cause="Unsufficient funds"; alert.reference=rh.transaction["CurrentId"]; alert.to="[email protected]"; # rh.sendAlert(alert); # By default we do nothing, so the movement stays in the queue. # By default rh.sendAlert(alert); are commented. Uncomment to send alerts The following methods or functions will be accessible: • boolean attemptToRelease(String WorkflowTransitionKey, boolean ExternalMessage) • releaseForcibly(String WorkflowTransitionKey, boolean ExternalMessage) 43 Configuring the Payment Flow Control Module • statusChange(String sage) WorkflowTransitionKey, boolean ExternalMes- • sendAlert() Each method or function is described below. • boolean attemptToRelease(String WorkflowTransitionKey, boolean ExternalMessage) This calls the limit check. If the limit check is successful, an Event containing the transaction data plus the new status retrieved from the (partial) WorkflowTransitionKey will be sent to the preprocessor in XML format (the same as the preprocessor output). If ExternalMessage is true, a full copy of the transaction is sent to the outbound formatter via MQ (with the new status). The WorkflowTransition is a record used to specify the Type and Status of the Event being generated. The Release Handler selects the WorkflowTransition, where the Type and Status and Channel match the one of the Transaction being processed, and the WorkflowTransitionId corresponds to the WorkflowTransitionKey. The update message (Event) will always contain the minimum required by the preprocessor, as follows: 1. Type. 2. AdapterStatus (retrieved from WorkflowTransition). 3. ValueDate. 4. Currency. 5. EventDateTime. 6. Branch. 7. In-Memory LockId. 8. LimitCheckType. Fields which are not updated are not filled in (left null). LimitCheckType is set to 1. If the limit check was passed successfully, the method returns to true. If the limit check was not passed successfully, the method returns to false. • releaseForcibly(String WorkflowTransitionKey, boolean ExternalMessage) This is the same as above, with the limit check done using the force option. The method will always succeed. The LimitCheckType is set to 2. • statusChange(String sage) WorkflowTransitionKey, boolean ExternalMes- This is the same as above, with no limit check. This can be used to release to a Channel when there is no limit on the Channel, or to move the payment to a hold state. LimitCheckType is not sent in the Event message. 44 Configuring the Payment Flow Control Module • sendAlert() This sends the current state of the transaction, augmented with the alert fields, to the configuration-specified MQ queue. For alerts, the Release Handler will send the current full image of the Transaction in XML format to the alert service, along with the message fields. By current, we mean that any change to the Adapter Status before the alert rule will be reflected in the alert XML message sent to the alert service. 4.4.4. PFC Workflow Configuration The business configuration of the PFC module is almost entirely via extensions to the basic workflow configuration of LMS. The following components are involved in PFC configuration: • Transaction Type • Transaction Status Records • Type Status Records • Workflow Transitions • Workflow States Note Workflow States, a new workflow record, has been added specifically for Payment Flow Control. The following are detailed examples of the base business configuration for PFC. 4.4.4.1. Configuring Transaction Types Normally, Transaction Types do not change when PFC is implemented with LMS. Rather, new states occur in the workflow for existing transaction types. In the discussions below, only the Expected Payment transaction type (– EP) is illustrated. The illustrated states should be added for each transaction type that is subject to limit and release processing workflow configuration. The following subsection describes the workflow configuration and the various tables that are involved. 4.4.4.2. Configuring Transaction Status Records Transaction Status records (also referred to as Status records) that reflect the release process steps should be added to the LMS workflow configuration. The Status records described below are delivered with the base PFC configuration: Status Record Meaning Definition HD Hold Release For transactions that have failed limit check. RL Released For transactions that have been successfully released. 45 Configuring the Payment Flow Control Module RM Release Manual For transactions that have been manually released. HH Manually Hold For transaction that have been manually placed in a HOLD state. LC Late Cancellation For Transactions that have been cancelled after they have been released 4.4.4.3. Configuring TypeStatus Records TypeStatus records need to be added to the LMS work flow configuration to reflect the added combinations resulting from the new states outlined above. The following table displays examples of TypeStatus records included with the base PFC delivery. None of the new TypeStatus records represent an initial state, but rather an intermediate state between expected and final states. 4.4.4.4. Configuring Workflow Transitions Workflow Transition Records are required to support the PFC workflow. The table below illustrates the Workflow Transition records for London, using Channel CHAPS. Entity Channel Type from Type to Status from Status to Manual Allowed Automat- Workic Trans- flow ition Transition LONDON CHAPS EP EP FX HH YES NO HARDHOLD LONDON CHAPS EP EP HD HH YES NO HARDHOLD LONDON CHAPS EP EP HH RM YES NO MANUALRELEASE LONDON CHAPS EP EP FX RL YES YES RELEASE LONDON CHAPS EP EP RM RL YES YES RELEASE 46 Configuring the Payment Flow Control Module Entity Channel Type from Type to Status from Status to Manual Allowed Automat- Workic Trans- flow ition Transition LONDON CHAPS EP EP HD RM YES NO MANUALRELEASE LONDON CHAPS EP EP FX HD YES YES HOLD LONDON CHAPS EP EP FX RM YES NO MANUALRELEASE LONDON CHAPS EP EP HD RL YES YES RELEASE The example above allows either manual updates or automatic transition, but not both. This is not a requirement, but is the recommended configuration. Note that the added workflow transition records must be added for each Channel subject to flow control. 4.4.4.5. Configuring Workflow States Workflow States is a new LMS workflow configuration in the PFC module. Workflow States are used to assign Type Status configuration to PFC processing steps. Workflow States are configured for each Channel that is subject to flow control. Note Particularly important is the Automatic HandlingYES/NO indicator. This is important as it determines whether the state can be processed automatically by the Release Handler. The table below illustrates the Workflow State records for Channel CHAPS. Type Status Channel Automatic Handler Handling EP EX CHAPS YES EP HD CHAPS EP RM EP EP Display Name Timed Handling LMS Handling RELEASE Workflow Point YES YES YES RELEASE Workflow Point YES YES CHAPS YES RELEASE Workflow Point YES YES RL CHAPS YES RELEASED Workflow Point YES YES HH CHAPS YES MANUAL Workflow RELEASE Point YES YES 4.4.5. Limits Configuration The following subsection describes limits configuration, including Limit Group Maintenance, Cross Reference Maintenance, and Limits Maintenance. 47 Configuring the Payment Flow Control Module 4.4.5.1. Limit Group Maintenance Limit Groups can be established using the Limit Group Maintenance function. Limit Groups allow the establishment of Group Limits with PFC. 4.4.5.2. Cross Reference Maintenance Cross Reference records are used to translate various external IDs into normalized internal IDs used within LMS. Cross Reference records are only required when the IDs in transaction records have not already been normalized in feeds from external systems or LMS alias processing. 4.4.5.3. Limits Maintenance For PFC to perform limit checking, it is necessary to define the limits themselves. If a Channel is subject to flow control and limits are not established in the system, limit checking will not take place. Release will take place without limit checking. LMS supports the following limit types: 1. Bilateral Limits – A limit on the net debit position of the counterparty bank in payment transactions at a Channel. For example, payments with CITIBANK, London at CHAPS. 2. Group Limits – A limit on the net debit position of a group of counterparty banks in payment transactions at a Channel. For example, CITIBANK Group (including CITIBANK, London; CITIBANK, New York; and CITIBANK, Tokyo) at CHIPS. 3. Multilateral Limits – A limit on the net debit position on the counterparty banks for which no Bilateral or Group Limits have been defined. In effect, an "everyone else" limit at a Channel. For example, a Multilateral limit at TARGET2. 4. Overall Limits – Effectively, the Overdraft limit to which the bank is subject at a Channel. For Example, the overall limit at TARGET2. The following are some other issues to be aware of: • Limits are established by Channel. • A Party can be part of both a Bilateral and a Group Limit at a Channel. • Overall Limits are applied to Total Liquidity used at a Channel. The Total Liquidity Used at a Channel is Opening Balance plus Actual Movements (if the value of payments is greater than the value of receipts, this is a negative number) plus Assets Pledged Balance. • Overall limits of zero (0) indicate that the Negative Limit used at the Channel is to prevent automatic release of payments. • Limit end dates are used to indicate the date at which a limit definition is to end. Normally this is used in conjunction with the establishment of new limit values for parties at a Channel. 4.4.5.3.1. Stream Limits Maintenance In addition to Channel Limits, the PFC Module allows Banks to set Limits against Stream Customer. So, in addition to checking whether there is sufficient Liquidity on the Channel, the PFC module will also check any Limits that apply to any stream Customer associated with the transaction. 48 Configuring the Payment Flow Control Module There are separate functions for setting up Stream Limits. These are: • Stream Limits • Stream Limits Verify There is also a separate Stream Limits Utilization screen, which will give details of the Liquidity available for specific Stream Customers. The stream Limits functions allows the Bank to set a limit for a specific Stream Customer. This is an overall Limit and, like the Channel Limit, is an intraday limit. Unlike the Channel Limit, Stream Limits require verification using Stream Limits Verification. 49 Chapter 5. Configuring the Collateral Manager Module The following section shows you how to configure the CMM module. 5.1. CMM - Data Requirements This subsection describes the data required to derive and display CMM positions. In most cases, the data described below will be automatically fed from internal or external system into LMS via LMS adaptors. In all cases, a manual function will be provided to support the manual input of the data. Where changes to an existing table are described, the related LMS Maintenance Screen will be modified to accommodate such changes. 5.1.1. CMM - Semi-Static Data Requirements The following LMS Semi-Static data tables will be used by the Collateral Manager Module without any modification. While the fields will not require any modification, it may be necessary to add additional records, as required by the CMM: • Aliases Table • Counterparties Table • DealerCurrency Table • ExchangeRates Table • Interest Rates Table 5.1.2. CMM - Static Data Requirements The following LMS Static data tables will be used by CMM without any modification. While the fields will not require any modification, it will be necessary to add additional records, as required by CMM: • Currencies Table • Locations Table • Originating Systems Table (Source System) • Responsible Unit Table 5.1.3. CMM - Configuration Data Requirements The following LMS Configuration tables will be used by CMM without any modification. While the fields will not require any modification, it will be necessary to add additional records, as required by CMM: • Matching Types Table • Position Impacts Table • Status Table 50 Configuring the Collateral Manager Module • Transaction Types Table • Workflow Transitions Table • Workflow States Table • Classifications Table • EOD Source Table • Operators Table • Profiles Table 5.2. CMM - Configuring Depositories In order to accommodate data computations, the depositories are implemented as two streams. The base stream is DepositoriesBase (the DepositoriesBase Table). Although the information is fairly straightforward, you must enter the date data as follows: • BaseDate: This is the date that you want the local current date to be. • CurrentDateOffset: Set this to 0 BusinessDate, etc. is computed by the data model, based on the calendar files in the system and should not be entered. Refer to the LMS Data Model Reference Guide to view all the tables in the LMS data model, including the DepositoriesBase table 5.3. CMM - Issue Details Processing The following describes how the Issue Details processing function works in the CMM module. The CMM module receives security information from multiple systems. This information is stored in the Issue Details table. Each source system may provide all or some of the issue details fields. All the source system data is combined in the Issue Details table based on a user-configuration source system ranking. The following describes the ranking system. 5.3.1. Ranking Issue Detail Fields CMM allows users to rank Issue Detail fields by Source System Category. To do this, users will: 1. Assign to a category all source systems that they want processed. Categories are not predefined; users can create them as needed. 2. Rank each field in Issue Details by Source System Category. 5.3.2. Two Streams in the Model There are two streams in the model to handle this collapse: 1. Issue Collapse Ranks 51 Configuring the Collateral Manager Module 2. Source System Categories The following describes the structure of these two streams: • IssueCollapseRanks • SouceSystemCategory (string) (key) • IssueColumnName (string) (key) • CollapseRank (string) • SourceSystemCategories • SourceSystem (string) (key) • SourceSystemCategory (string) 5.3.3. An Example of Ranking Issue Detail Fields Note The example below is for illustrative purposes only. It does not correspond to real data in any way. Assume that IssueDetails has the following four fields: • SecurityID • SourceSystem • AssetType • Currency Data from the following Source Systems is processed. Source Systems are categorized as follows: Source System SourceSystem Categories EuropeanBranch ECB LondonBranch ECB Woking MO Chicago BO Assume that you want the field collapse priorities to be as follows: • For AssetType: ECB - MO - BO 52 Configuring the Collateral Manager Module • For Currency : BO - MO - ECB To implement this, capture the following ranks: SourceSystemCategory IssueColumnName Rank ECB AssetType 1 MO AssetType 2 BO AssetType 3 ECB Currency 3 MO Currency 2 BO Currency 1 5.4. CMM - Matching Configuration The following subsection describes how to configure matching in the CMM module. This includes an explanation of the matching process, including the Preprocessor, matching rules, matching types, and workflow transitions. 5.4.1. CMM - Automated Collateral Matching Information The purpose of matching is to regroup a number of collateral transactions together to reflect the fact that these transactions are related to the same operation in the real world, and modify their status and impact on positions accordingly. Matching is necessary when it is not possible to establish a common reference in different events. Thus, the events cannot be collapsed into a single transaction. These multiple transactions would generally, artificially increase the position impact of the operation; matching allows these to be regrouped together, so that the position impact is corrected. The system will compare any two different collateral transactions and will attempt to match them based on criteria present in both transactions. Automatic collateral matching will be supported by a flexible rule-processing mechanism similar to the Cash Matching that can be described as a two-step process: 1. A rule is selected based on the content of the transaction that requires matching. Unmatched eligible events are then compared to the matching criteria listed in the rule. Both events are logically updated when the rule conditions are met. Ineligible events are ignored and marked. 2. If the rules conditions are not met, the system will repeat the process until either no further rule can be selected, or matching takes place. The rules will accommodate the bank’s processing needs and market practices. For example, the following scenarios must be covered: • There is no absolute certainty that an expected event will be present in the system before the actual event for settlement or pending (reservation). Advices of settlement received before the Expected 53 Configuring the Collateral Manager Module Transaction will be held as unmatched until the Expected Transaction is received. • Pending events will only be matched against later Expected Transactions. The matching criteria will be user-defined, within the following possible criteria defined: 1. Issue 2. Value date 3. Depository 4. Amount, with tolerance (face values) 5. Reference, one of the following: • Current ID • Previous ID • Originating System • Other reference field for Partial Matching 6. Counterparty The matching process will result in one or several of the following actions: 1. A change of status as defined in the Workflow transitions table. 2. A position update. 3. An update to the Transaction Matched Amount, Matched Position Time, Match ID and Remaining Face Amount. 4. A decision not to attempt any match with the first event. The following table lists the types of transactions that can be matched: Expected Transaction Actual Transaction Expected to be settled at value or ma- Can be matched to one or sevturity date. These are represented in eral different transaction types and status. See Type status worksheet. Notice of delivery or receipt (ADL or ARC), normally from the depository. Note: there is also a valid manually matched one to many conditions. For example PUR BK or REP CF will match ARC US Pending Transactions Pending Delivery Expected Transaction Can be matched to several (0..n) 54 Matched against one or more Expected Transactions Configuring the Collateral Manager Module 5.4.1.1. Example of Collateral Rule Definitions This example is intended to clarify the functionality rather than assist with the actual implementation. The existing LMS matching process will be used, but some modifications may be required. Name Value Type of matching Expected Transaction to Pending Partial Allowed Rule sequence 1- Highest Select rule for Transaction Type Expected Event Type Select rule for Depository equals Any Select rule for amount > 1M (expressed in nominal currency units). Specific rules can be stipulated by currency. Other criteria for rule selection… Match on Currency Yes Match on Issue Yes Match on Amount No (N/A for partial) Amount tolerance 50,000 (expressed in nominal- transaction- currency) Match on Value Date Yes Match on Depository Yes Use Partial Matching Yes Partial Matching tolerance 10,000 Other criteria for matching…. Note For specified events such as small actual amounts, the system might not attempt to perform matching; the status being defaulted to self-matched. This operation is selected according to the same criteria for rule selection that is described above. 5.4.1.2. Matching Amounts 55 Configuring the Collateral Manager Module The transaction record contains the following amounts: 1. The original face amount ( OriginalFaceAmount). 2. The original settlement amount ( OriginalSettledAmount). 3. The residual face amount that remains to be matched. This is not necessarily equal to (original – matched) because of cancellations (RemainingFaceAmount). 4. The nominal amount matched (sum of amounts for all records matched to this particular transaction) (Matched Amount). The following are other issues to consider: • Matching will be done against the RemainingFaceAmount. • The RemainingFaceAmount equals the OriginalFaceAmount if the transaction has not been matched. • When doing partial matching, the RemainingFaceAmount is calculated by subtracting the amount(s) of the transaction(s) that a transaction has been matched to. • If a Transaction is not marked as Partial Matching, then the remaining amount is zero once the transaction has been matched. • The RemainingFaceAmount never goes below zero. The following table describes matching amounts in greater detail. Transaction Fields Transaction A Before Match Transaction B Before Match Transaction A After Match Transaction B After Match OriginalFaceAmount 10,000,000 2,000,000 10,000,000 2,000,000 OriginalSettledAmount 10,460,000 2,092,000 10,460,000 2,092,000 RemainingFaceAmount 10,000,000 2,000,000 8,000,000 0 MatchedAmount 0 0 2,000,000 2,000,000 5.4.1.3. Partial Matching or One-to-Many Matching Matching can be full or partial. For example, one pending Transaction could be matched against several expected Transactions, or vice versa. Partial matching is supported by the automated matching process of CMM. The system does not allow many-to-many matching. In a group of matched transactions, the Partial Match flag can be used to mark the one transaction that the rest will match against. The Partial Match flag should only be set by the matching function when a pair of transactions that have not been previously matched are matched using a reference, and the remaining face amount of one of them is more than a set tolerance amount. The transaction with the remaining amount > set tolerance amount will be marked as Partial Match = Y. 56 Configuring the Collateral Manager Module • If the transaction has been matched, this flag will not be changed manually or automatically. • If the transaction is manually unmatched, then the flag should be reset by the matching function. The matching rules specify: • Whether partial matching can be done in this particular rule. • What the tolerance amount is (that is, the difference between the transactions). This triggers the partial matching processing. The following is an example. Id Transaction A Transaction C Type TranA TranB Status PUR ARC Amount CF US Reference 14,500,000 10,000,000 Security Id MMDESK01 MMDESK01 Partial Match NL324 NL324 Transaction A and Transaction B will be matched, assuming rules are set to match based on value date, issue and reference, as follows: Id Transaction A Transaction B Type PUR ARC Status CF MS Amount 14,500,000 10,000,000 Reference MMDESK01 MMDESK01 Security Id NL324 NL324 Partial Match 1 0 Matched Face Amount 10,000,000 10,000,000 Remaining Face Amount 4,500,000 0 57 Configuring the Collateral Manager Module Matched Id TranB TranA The following is the third transaction, Transaction C: Transaction ID Transaction C Type Tran C Status ARC Amount US Reference 4,500,000 Security ID MMDESK01 Partial Match NL324 The following shows that Transaction C will match Transaction B, as follows: ID Transaction C Transaction B Type ARC PUR Status MS SE Amount 4,500,000 14,500,000 Reference MMDESK01 MMDESK01 Security ID NL324 NL324 Partial Match 0 1 MatchedFaceAmount 4,500,000 14,500,000 RemainingFaceAmount 0 0 Matched Id TranA TranB, TranC When the transaction is matching to another, the status of the Matched transaction will be changed to the status described in the Workflow Transitions table. Refer to the LMS Data Model Reference Guide for specific information concerning the WorkflowTransitions table. The Remaining Face Amount of the Matched transaction can be manually cancelled using the CMM Bulk Matching Function. 58 Configuring the Collateral Manager Module 5.4.2. CMM - Matching Rules The following subsection will help you configure matching rules in the CMM module. 5.4.2.1. CMM Transaction Statuses The following describes CMM transaction statuses and their definitions. Transaction Status Description AC Accepted BK Booked CA Cancelled CF Confirmed DU Duplicate EX Expected MS Matched Settled RJ Rejected SE Settled PS Part Settled US Unmatched Settled CR Manual Cancelled/Unsettled MT Matured Complete 5.4.2.2. CMM Transaction Types The following tables describe CMM transaction types, specifically Expected Transaction Types, Actual Events, and Opening Balance Movements. Table CMM Expected Transaction Types Transaction Type Description PUR Purchase SEL Sell PRC Pending Receipt 59 Configuring the Collateral Manager Module PDL Pending Delivery LOA Loan BOR Borrow REP Repo SBB Sell/Buy Back RRE Reverse Repo BSB Buy/Sell Back CPL Customer Pledge CWD Customer Withdrawal RES Other use LPL Pledge LWD Withdrawal EDL Expected Delivery ERC Expected Receipt Table CMM Actual Events Transaction Types Transaction Type Description ARC Actual Receipt ADL Actual Delivery AMD Actual Manual Delivery AMR Actual Manual Receipt Table CMM Opening Balance Movements Transaction Types Transaction Type Description BFA Automatic Free Balance BPA Automatic Pledge Balance 60 Configuring the Collateral Manager Module BFM Manual Free Balance BPM Manual Pledge Balance 5.4.2.3. Notes Concerning the Design of the CMM Matching Rules The following notes will help you understand how the CMM matching rules were designed: • The cash side of CMM matching behaves as it does in CFM. However, the collateral securities require a separate set of rules. • Although CMM matching has separate rules, conceptually the rules follow the same design. As in CFM matching, we use the idea of “expected” and “actual” transactions matching to move positions from expected to actual. • The Expected Transaction Types table start on the expected side, but can end up on the actual side. • The Actual Events Transaction Types are always on the actual side. 5.4.2.4. An Example of Matching in the CMM Module Assume we have a transaction fed into the system as a PUR. This transaction can have a number of valid statuses, and could have a workflow as follows: Event ID Transaction Type Status Action ABCDEFG123 PUR BK Initial event ABCDEFG124 PUR CF Event confirmed ABCDEFG125 PUR SE Event settled ABCDEFG126 PUR US Settled but unmatched At this point, we receive the actual side, as follows: Event ID Transaction Type Status Action ANOTHER ref ARC MS Settled and matched ABCDEFG126 PUR MS Settled and matched These two transactions are now matched and are shown only in the actual position. This scenario can be extended to more complex products, because in effect, all transactions come down to manual, or auto-feed, receipt or delivery of the security. 5.4.2.5. Duplicate Processing with CMM 61 Configuring the Collateral Manager Module As with CFM matching, with CMM matching, we have pending and expected transaction types. Therefore, duplicate processing would work in the same way. 5.4.2.6. An Example of Duplicate Processing using CMM The following is an example of duplicate processing. Event ID Transaction Type Status Action ANOTHER ref SEL CF Transaction received INTERNAL ref PDL EX Manually entered event EXTERNAL ref SEL US Actual unmatched event After the matching engine processes, the following might occur: Event ID Transaction Type Status Action ANOTHER ref SEL MS Matched to actual INTERNAL ref PDL DU Duplicate matched to SEL EXTERNAL ref ADL US Matched to SEL Duplicate and expected positions are deleted, leaving only the actual positions. 5.4.2.7. Filter Rules with CMM The following transaction types are filtered from the matching process: Transaction Types Filtered CPL Free deposit of security. CWD Free loan of a security. LPL Free deposit of security to the Central Bank. LWD Free loan of a security to the Central Bank. BFA Opening balance movement carried forward from previous day or one-off adjustment. BPA BFM BPM 62 Configuring the Collateral Manager Module The following status types are filtered from the matching process: Status Types Filtered CA Cancelled, so there is nothing to match to. RJ Rejected. 5.4.2.8. Matching Rule Configuration File The following is the matching rule configuration file: # Matching Rule configuration file # # Filtering Rules # # This filtering rule blocks selected transaction types from match processing # filter { ID: 1 field: TransactionType :in: [CPL,CWD,LPL,LWD,BAA,BAM,RES] } # # This filtering rule blocks selected transaction statuses from match processing # filter { ID: 2 field: AdapterStatus :in: [AC,CA,RJ,CR,MT] } # # This filtering rule blocks reversed transactions # filter { ID: 3 field: Reversed = 1 } # # Selection Rules # # If the incoming receipt is an Expected, look at all existing Pending # Receipts and run Match Rule 100 against the resulting pairs (duplicate detection) # selection { ID:10 priority:1 incoming: Transaction Type :in [PUR,LOA,BOR,REP,SBB,RRE,BSB,ARC,AMR,ERC] existing: TransactionType = PRC selfmatch: 0 matchrule: 100 } 5.4.3. CMM - Designating Pledgeable Channel Records LMS includes an option to define those channels with whom the Bank will conduct Pledge Transactions. There is a Pledgeable flag on the Channel record, and this must be set to true if this Channel is to be used for pledging. By default, each Channel is set to false. Only those Channels with a true flag will feature in those inquiries and capture functions that are named Pledged Channel or Potential Pledge Channel. 63 Configuring the Collateral Manager Module • To designate a Channel record as a Pledgeable Channel On the Channel's record, set the configuration flag to True. Perform this action for all applicable Channels. 64 Chapter 6. Post-Configuration Information Now that you have performed the LMS business configuration, you must: • Ensure that the feeds are properly entering LMS. • Test the LMS business configuration. • Maintain the LMS business configuration. The following subsections describe these post-configuration actions in more detail. 6.1. Ensuring that Feeds are Properly Entering LMS In order for LMS to give proper results, you must ensure that the proper feeds coming into the bank from external sources are actually entering LMS. SAP suggests that you work with technical team members and the IT infrastructure group to ensure that proper feeds are coming into LMS. Note This assumes that you have already defined the feeds that will be coming into LMS. Once feeds are set up, the data feeds are usually controlled by System Operations, with manual updates and inputs performed by authorized operators at the bank. 6.2. Testing the LMS Business Configuration Business Analysts develop test cases prior to User Acceptance Testing (UAT). They ensure that calculations derive the correct answers, ensure that LMS works the way they intend it to work, and so on. Note Testing the actual LMS business configuration is beyond the scope of this document. This section is merely provided to inform users that this step is crucial to the successful use of LMS. 6.3. Maintaining the LMS Business Configuration On an ongoing basis—as business and data sources change over time—Business Analysts must modify and test the LMS business configuration. The information that follows gives you a very general overview of the items that must be maintained in the LMS business configuration. Note This guide does not cover maintenance functions for the Liquidity Insight Module. 6.3.1. Maintenance Functions for the CFM Module The following section describes the maintenance functions for each of the LMS modules. Refer to the LMS User’s Guide for specific procedures on how to maintain LMS. The CFM Module provides online functions to maintain Semi-Static data, Static data, and Configuration parameters required by LMS. Maintenance functions (capture, update, delete) for CFM include the following: 65 Post-Configuration Information • Semi-Static Data Maintenance Functions • Static Data Maintenance Functions • Configuration Parameter Maintenance Functions • Balance Transfer Rules Maintenance Functions • Channel Support Maintenance Functions • System Management and Maintenance Functions 6.3.1.1. CFM - Balance Transfer Maintenance Functions The following are Balance Transfer Rules maintenance functions for CFM: • Scheduled Balance Transfers • Balance Transfer Rules • Transfer Set Maintenance • Cross Reference Maintenance • Manual Transfer Sweeps 6.3.1.2. CFM - Channel Support Maintenance Functions The following are Channel Support maintenance functions for CFM: • Channel Definition • Sub Channel 6.3.1.3. CFM - Configuration Parameter Maintenance Functions The following are Configuration parameter maintenance functions for CFM: • Balance Types • Matching Types • Position Impacts • Renewal Type • Status • Transaction Type • Type Status • Workflow Transition 66 Post-Configuration Information • Classification 6.3.1.4. CFM - Semi-Static Data Maintenance Functions The following are Semi-Static Data maintenance functions for CFM: • Alias • Correspondent Rates • Responsible Unit Rates • Exchange Rates • Interest Rates • Significant Event Maintenance • Excluded Parties 6.3.1.5. CFM - Static Data Maintenance Functions The following are Static data maintenance functions for CFM: • Currency • Location • Originating System • Entity • Responsible Units 6.3.1.6. CFM - System Management and Maintenance Functions The following are System Management and maintenance functions for CFM: • End of Day (EOD) Parameters • Profile • Profile Verify • Operator • Operator Verify • Workload Allocation • Workload Allocation Verify • DDS Function Maintenance 67 Post-Configuration Information • DDS Function Maintenance Verify • DDS Profile Maintenance • DDS Profile Maintenance Verify • System Administration 6.3.2. Maintenance Functions for the PF Module The following section describes the maintenance functions for the PF Module. The PF Module provides online functions to maintain the semi-static and Static data and Configuration parameters required by LMS. Maintenance functions (capture, update, delete) for PF include the following: • Semi-Static Data Maintenance Functions • Static Data Maintenance Functions • Configuration Parameter Maintenance Functions 6.3.2.1. PF - Configuration Parameter Maintenance Functions The following are Configuration Parameter maintenance functions for PF: • Product • Stream Movement Type 6.3.2.2. PF - Semi-Static Data Maintenance Functions The following are Semi-Static data maintenance functions for PF: • Business Unit • Counterparty • Dealer Currency • Stream Customer Account • Stream Customer • Sort Code • Stream • Stream Customer Default Anticipated 6.3.2.3. PF - Static Data Maintenance Functions The following are Static Data maintenance functions for PF: 68 Post-Configuration Information • Cross Booking Lines 6.3.3. Maintenance Functions for the PFC Module The PFC Module provides online functions to maintain the Semi-Static data, Static data, and Configuration parameters required by LMS. Maintenance functions (capture, update, delete) for PFC include the following: • Party Maintenance • Limit Definition • Limits Utilization • Request Initiation • Reconciliation • Stream Limits • Stream Limits Verify • Check Queues • Response Messages Enquiry 6.3.4. Maintenance Functions for the Liquidity Risk Manager This guide does not cover maintenance functions for the Liquidity Risk Manager. 6.3.5. Maintenance Functions for the CMM Module The following section describes the maintenance functions for the CMM Module. The CMM Module provides online functions to maintain Semi-Static data, Static data, and Configuration parameters required by the LMS. Maintenance functions (capture, update, delete) for CMM include the following: • Semi-Static and Static Data Maintenance Functions • Event Maintenance Functions 6.3.5.1. CMM - Event Maintenance Functions Event maintenance functions to capture, update (including cancellation) and delete on any type of securities event. Any of these functions optionally allow verification. Collateral events are: • Collateral Transaction Maintenance 6.3.5.2. CMM - Semi-Static and Static Data Maintenance Functions LMS will maintain the Static data and parameters for CMM. CMM maintenance functions (capture, update, delete) exist for the following: 69 Post-Configuration Information • Entity Details • Asset Type Alias • Country Codes • Entity/Close Links • Depository Details • Safe Keeping Account Details • Eligibility Rating • Liquidity Rating • Issue Details • Haircut Issue Channel Details Maintenance • Reserve Purpose • Security Id Alias Maintenance • CMM Type Status • Collateral Position Type Status • CM Workflow Transition This is a partial list. More general parameters are stored inside text configuration files. 70 Chapter 7. Workflow Monitoring and Position-Keeping Functionality The following section describes the various workflow monitoring and position-keeping functionality of each of the CFM Modules. 7.1. CFM - Workflow Monitoring and Position-Keeping Functionality The following subsection describes the various workflow monitoring and position-keeping functionality of the CFM Module. 7.1.1. CFM - Account Balances and Balance Management LMS records Balance Movements representing Opening Balances on the Account, the Cash Value of Assets Pledged to the account (Collateral Value), and Overall Limits on the Account. Wherever possible, balance movements are generated automatically from the banks source systems. Changes to balances, such as the cash value of assets pledged and limits, are supported by both feeds from existing systems and manual input functions. The Balance Management function supports the manual capture and update of balances such as Channel Opening Balance, Regulatory reserves, Assets Pledged balances, threshold amounts, and limit amounts. When updating balances, it is possible to configure the Balance Type so that any new balance being entered will replace any existing balance, while other updates can add to the existing balance. This can be configured by the Bank through the Balance Movement Semi-static record. This will apply to both manual and automatic updates. 7.1.2. CFM - Transaction Recording Liquidity events can be captured, updated, or deleted. Selected data is validated and derived against the Static data. This happens in real time 24/7. LMS event record is able to support multiple identifiers coming from the different source systems. The event records for a transaction reflect all of the steps that a transaction has gone through within the bank’s payment processing workflow. To prevent duplicates, the system will not record a transaction with the same ID more than once, but may, if appropriate, update information such as status upon receipt of a new feed event. Events are combined by LMS into internal liquidity transactions. The transactions represent liquidity flows that are aggregated into various positions within the system. Transactions can represent external activity and internal (book transfer) activity. This is clearly indicated on the events within the LMS database. The following transaction types are delivered with the CFM Module and are defined as follows: Transaction Type Definition Expected payment Expected payments are usually generated from data provided from existing bank systems (manual input is also supported) representing settlement/payment transactions that are expected to cause an outflow of funds from the bank. Expected payments will update the expected movement positions of LMS until they are marked as “Complete.” At that time, they will be removed from the expected position and included in the actual position. Cancelled Expected payments will be removed from the expected position. Examples of expected payments are settlement of a security purchase transaction or a customer payment order. 71 Workflow Monitoring and Position-Keeping Functionality Transaction Type Definition Expected receipt Expected receipts are usually generated from data provided from existing bank systems (manual input is also supported) representing settlement/payment transactions that are expected to cause an inflow of funds from the bank. Expected payments will be removed from the expected position when matched to an actual receipt or cancelled. Examples of expected receipts are settlement of a security sale transaction, response to an MT210 received from a counter party bank, or a scheduled loan repayment customer account. Pending payment Pending payments, usually recorded manually, represent a significant outflow of funds that is likely to take place at some time during the processing day. The transaction has not yet been recorded in any bank system. Examples of Pending Payments would be an expected disbursement of a new loan or an expected settlement of planned securities purchases. Pending receipt Pending receipts, usually recorded manually, represent a significant inflow of funds that is likely to take place at some time during the processing day. The transaction has not yet been recorded in any bank system. Examples of Pending receipts would be an expected prepayment of a commercial loan or an expected settlement of planned securities sales. Actual receipt Actual receipts reflect confirmed flows of funds into one of the bank’s channels (Nostro accounts). Examples of Actual receipts are responses to an MT910 from a channel (Central Bank or other Nostro agent), created by entries included in an MT942 received from a channel, or a message from the bank’s existing payment system that funds have been received in a channel. Netted payment Netted payments are usually generated from data provided from existing bank systems (manual input is also supported) representing settlement/payment transactions that are expected to create a Debit to the account identified in the transaction and Credit a netting account. The balance of the netting account will then be settled by a separate payment or receipt transaction. An example is the sold side of a foreign exchange trade subject to a netting agreement. Netted receipt Netted receipts are usually generated from data provided from existing bank systems (manual input is also supported) representing settlement/payment transactions that are expected to create a Credit to the account identified in the transaction and Debit a netting account. The balance of the netting account will then be settled by a separate payment or receipt transaction. An example is the bought side of a foreign exchange trade subject to a netting agreement. Netting payment Same definition as an expected payment, where the Debit account is a netting account. Netting receipt Same definition as an expected receipt where the Credit account is 72 Workflow Monitoring and Position-Keeping Functionality Transaction Type Definition a netting account. Other Transaction Types can be defined using the Configuration functions outlined below. Cancellations and Amendments may be received for all transactions. On receipt of an Amend or Cancel the following occurs: • Cancellation: • Update status of transaction to ‘Cancelled.’ • Remove the transaction amount from any positions. • Amendment: • Update transaction with new details. • Update corresponding positions with new financials. • Ensure that any changes are logged. 7.1.3. CFM - Recording Transaction Status Each Liquidity Transaction will change status throughout its life cycle. The life cycle starts when the transaction is entered into the system and finishes at the closing of the transaction value date. Transaction status will change based on: • Manual or automatic update to the liquidity transaction • Matching • Expiration • Manual update to the status • External automatic update to the status Different statuses and status rules can be attributed to each transaction type. For each transaction type, there is a workflow that defines the legal status changes and the circumstances under which such changes will apply. The system uses a status of “DU” to prevent duplication of position impacts from two transactions representing the same underlying activity. An example is when a Pending payment is matched to an Expected payment. In this case, the Pending payment is marked with a status of “DU” and removed from the Cash Position. The combinations of Transaction Type and Status will vary based on each bank’s practices, system environment, and market practices. Therefore, the implementation of the status workflow logic inside the application is reasonably open so that modifications can be done without major effort. 73 Workflow Monitoring and Position-Keeping Functionality 7.1.4. CFM - Status Change Actions Each status change can generate a specific action. The actions can be one or several of the following: • Recalculation of the positions. • Change the presentation of positions when a predefined threshold is reached close to the currency cut off time, using color coding to draw the attention of the monitors (Red/Amber/Green or RAG). • Sending a screen or E-mail notification based on the type of status change. 7.1.5. CFM - Positions and Calculations Transactions will be aggregated based on their type, specific transaction data, and current status. 7.1.6. CFM - Cash Positions The following table summarizes the cash positions. Position Description Opening Balance The opening balance for an account. Usually taken from an overnight batch feed. It may be updated for back-valued transactions. Inquiries will indication that the balance has been adjusted and drill down to the movements. Actual Movements These are complete payments, actual receipts. Calculated Actual Balance Opening Balance plus Actual Movements. Actual Balance The Actual Balance in an account balance usually updated from an automatic feed from the account holding bank or a Real Time Nostro feed. This is not an aggregation. In this case the last received figure simply replaces the previous one. Virtual This is an optional Position Bucket and could be used for instance to record those payments that have been released but for which the Bank have not received an ACK through the SWIFT system. Expected Expected Movements. These are payments that are not complete and unmatched expected receipts. Pending Pending movements always entered manually. Can be seen as specifically monitored items. Pending movements are either replaced by expected or actual movements or cancelled. Forecast Cash Calculated Actual Balance or Actual Balance plus Expected Movements plus Pending Movements. Assets Pledged Balance of the Cash Value of Collateral pledged to the Channel. Assets Pledged balances may be a single figure or the sum of several subsidiary account (Subchannel) balances. For example, the Assets Pledged balance at the Central Bank may be a single figure or the sum of Subchannel balances for RTGS, Securities and eli74 Workflow Monitoring and Position-Keeping Functionality gible loans. Limit The overall limit for the channel. Forecast Liquidity Forecast Cash plus Assets Pledged plus Limit. The expected position is split into discrete time positions that will accumulate the transactions based on their expected execution time (see Time assignment) The system provides the ability to create rules to support the transaction aggregation rules based upon Transaction Type and Status. 7.1.7. CFM - Decision Support LMS provides the ability to monitor, report, and view information in real-time to facilitate the management of cash positions. The system provides standard liquidity views. 7.1.8. CFM - Standard Position Views The following are standard position views: • Currency Position Summary • Cash Position Summary (All Channels) • Channel Summary • Channel Timed Forecast (Table and Graphical views) • Projected Cash 3 Days by Channel • Consolidated Positions Navigation between liquidity views and maintenance functions following defined business rules is available. Standard views, where appropriate, support sorting by column and warnings of excessive data from imprecise selection. You can export the data viewed in all position queries and transaction queries to an Excel file. 7.1.9. CFM - Standard Transaction Inquiries The following are standard transaction inquiries in the CFM Module: • Transaction Manager • Transaction Manager New • Cash Transaction Summary • Event Manager 75 Workflow Monitoring and Position-Keeping Functionality For transaction inquiries, the selection criteria allow selection by currency, clearing channel, customer, entity, date, time, transaction status, and other values in the transaction record, as well as combinations of the criteria. For example, selection criteria would support a query to select all transactions in USD for ABC Corp. from the New York Branch that were “Actual” between 10:00 and 12:00 on 15 November 2006. Following the selection of a group of transactions, you can export the data to an Excel file. 7.2. PF - Workflow Monitoring and Position-Keeping Functionality The following subsection describes the various workflow monitoring and position-keeping functionality of the PF Module. 7.2.1. PF - Anticipated Stream and Wholesale Positions The Anticipated Stream and Wholesale positions in the PF Module will summarize the bank’s estimation for the end-of day cash positions. The position types that will be supported are: Position Projected Cash Booked In Booked Out Anticipated In Anticipated Out The projected positions summarize cash activity from multiple systems, customers, and bank’s business line/unit. Transaction input is both automatic and manual. There is a hierarchy of positions and the ability to drill down to the next position level down up to the transaction detail. 7.2.1.1. PF - Stream Positions Stream positions are intended to track the real-time net balances for selected party accounts and support the anticipation of cash flows emanating from those accounts. The notion of stream position can be summarized as follows: Stream - regroups ® Customer/Business Unit – Who owns ®#Accounts A stream regroups customers or Business Units within the bank, which have a number of accounts. Movements create debits or credits to these accounts. A movement can impact two streams: the DR side and the CR side. The stream summary reflects a real-time current Net Balance for the group of accounts being tracked and allows drill down to a manual input function for anticipated movements. The anticipated movements reflect expected cash flows that have not yet been ordered by the parties in the stream group. The system provides inquiries at summary, party, and account-detail levels with drill downs into the movements creating the balances displayed. 76 Workflow Monitoring and Position-Keeping Functionality Opening Balance + Net Ins – Net Outs = Net Balance The system holds a list of customers/Business Units and their accounts for which these positions are kept distinctly. The position includes both external and internal movements that affect the accounts. 7.2.1.2. PF - Projected Wholesale Positions Projected Wholesale Positions reflect the known contractual Funding activity of the bank and the anticipated additional internal funding transactions required for the day. The sources of the information are the deals from the Money Market system(s) (bookings) and anticipated movements. When a department (or Business Unit or BU) is long or short, it will pass this position to treasury/Money Market. Money Market will in turn give or take a deposit for this amount. The Projected Wholesale Summary inquiry allows drill-down to a manual input function for anticipated movements. The anticipated remaining = Anticipated – Money Market bookings (that corresponds to the transfers to treasury and funding deals being made). Anticipated remaining goes towards zero during the day. The wholesale area is divided per ‘activity’ or Business Units (BU), such as Commercial Lending, Commodities, Forex, Derivatives, and so on. LMS holds the BU definitions in user-maintainable tables. LMS also checks a second relationship (Dealer + Currency) to Business Unit, and if found, will position the movement in the BU line as anticipated. In a schematic way, this can be presented as follows for one Business Unit. In Out Net = (In – Out) Anticipated Anticipated In Anticipated out Net Anticipated Bookings Booked in Booked Out Net Booked = Anticipated – Booked = Anticipated – Booked Anticipated remain- =Anticipated – ing Booked Projected Cash =Anticipated remain- =Anticipated reing + Booked maining + Booked =Anticipated remaining + Booked As you can see, the projected cash is expected to remain constant provided that the anticipated movements were estimated correctly (so these are approximate equalities). During the day, the positions move from anticipated to booked, the total remaining constant. 7.2.2. PF - Standard Position Views The following are standard positions view in the PF Module: • Projected Cash Position Summary • Projected Wholesale Positions • Stream Summary Positions • Stream Detail 77 Workflow Monitoring and Position-Keeping Functionality • Customer Accounts • Swing Balance • Position Freeze Navigation between liquidity views and maintenance functions following defined business rules is available. Standard views, where appropriate, support sorting by column and warnings of excessive data from imprecise selection. You can export the data viewed in all position and transaction queries to an Excel file. 7.2.3. PF - Standard Transaction Inquiries The following are standard transaction inquiries in the PF Module: • Wholesale Transaction Summary • Streams Transaction Summary For transaction inquiries, the selection criteria allow selection by currency, clearing channel, customer, entity, date, time, transaction status, and other values in the transaction record, as well as combinations of the criteria. For example, selection criteria would support a query to select all transactions in USD for ABC Corp. from the New York Branch that were “Actual” between 10:00 and 12:00 on 15 November 2006. Following the selection of a group of transactions, you can export the data to an Excel file. 7.2.4. PF - Transaction Recording The following table defines the transaction types delivered with the PF Module of LMS. Transaction Type Definition Anticipated payment Usually a manually generated transaction; part of the PF process. Identifies a possible payment from either a customer or bank unit account. Anticipated receipt Usually a manually generated transaction; part of the PF process. Identifies a possible receipt into either a customer or bank unit account. 7.3. CMM - Workflow Monitoring and Position-Keeping Functionality The following subsection describes the various workflow monitoring and position-keeping functionality of the CMM Module. 7.3.1. CMM - Transaction Recording Collateral events can be captured, updated, or deleted. Selected data is validated and derived against the static data. This happens in real time (24/7). The events support multiple identifiers coming from the dif78 Workflow Monitoring and Position-Keeping Functionality ferent source systems, which in turn allow multiple events to be linked to a single transaction. The event records for a transaction reflect all of the steps that the transaction has gone through within the bank’s processing workflow. Collateral events are combined by CMM into internal collateral transactions. The transactions represent collateral movements that are aggregated into various positions within the module. Transactions can represent external activity and internal activity (trading or book transfer). This will be clearly indicated in data feeds (this could be an account, a flag, or other specified data) and on the events within the CMM database. Transactions types delivered with CMM are defined as follows: Transaction Type Definition Expected purchase Event generated by an internal bank system that is expected to cause an outflow of funds from the bank against receipt of a security. Expected sale Event generated by an internal bank system that is expected to cause an inflow of funds to the bank against delivery of a security. Pending receipt Manually generated event that is expected to create a deposit of securities into the account identified in the transaction. This will optionally be used to pre-notify securities transactions that are not yet entered into the trading systems. Expected Borrow Event generated by an internal bank system that is expected to cause receipt of a security on the value date and delivery of the same security on the maturity date. Collateral against securities borrowed would be treated as a loan event. Expected Repo (repurchase agreement) Event generated by an internal bank system that is expected to cause an inflow of funds to the bank against delivery of a security on value date and have the opposite movements at maturity. Expected Sell/Buy Back Event generated by an internal bank system that is expected to cause an inflow of funds to the bank against delivery of a security on value date and have the opposite movements at maturity. Compare Expected Repo Expected Reverse Repo Event generated by an internal bank system that is expected to cause an outflow of funds from the bank against receipt of a security on value date have the opposite movements at maturity. Expected Buy/Sell Back Event generated by an internal bank system that is expected to cause an outflow of funds from the bank against receipt of a security on value date have the opposite movements at maturity. Compare reverse Repo. Expected Customer Pledge Event generated by an internal bank system that is expected to cause the receipt of a security that can be lent or otherwise used as collateral by the Bank. 79 Workflow Monitoring and Position-Keeping Functionality Transaction Type Definition Customer Withdrawal Event generated by an internal bank system that causes an outflow of a security from the Bank’s custody account when it is released back to the customer. Other Use Event generated in the Collateral Manager recording use of eligible assets from existing inventory for a use other than liquidity provision. An example is a tender credit with the central bank or an issue that is set to ‘special’. Expected Pledge Event generated by the Collateral Manager that requests a custodian to deliver or hold a specific amount of security to the order of a clearing organization or central bank. Expected Withdrawal Event generated by the Collateral Management system that requests a clearing organization or central bank to release a stated amount of collateral held back into our account with the depository. Actual manual delivery This is an adjustment, where through some source the monitors know that a delivery out of our depository account has taken place, but is not reflected in the normal feeds Actual manual receipt Same definition as manual delivery, for receipt. Balance Update Automatic or manual event that creates Opening Balances in the CMM Other Transaction Types can be defined using the configuration functions provided with LMS. Cancellations and amendments may be received for all transactions. The Amend or Cancel event will contain the event reference and the new movement details in order that the original transaction can be identified and updated. On receipt of an Amend or Cancel, the following should occur: Cancellation • Update status of event to ‘Cancelled.’ • Remove event from any positions. Amendment • Update event with new details. • Update corresponding positions with new financials. • Ensure that any changes are logged. 7.3.2. CMM - Recording Transaction Status 80 Workflow Monitoring and Position-Keeping Functionality Each collateral transaction will change status throughout its lifecycle. The lifecycle begins when the transaction is entered into the system and finishes at the closing of the transaction value date. • Transaction status will change based on: • Manual or automatic update to the collateral transaction • Matching • Expiration • Manual update to the status • External automatic update to the status Each transaction type can be attributed different statuses and status rules. For each transaction type, there will be a workflow that will define the legal status changes and the circumstances under which such changes will apply. This will vary based on each bank’s practices, system environment, and market practices. Therefore, the implementation of the status workflow logic inside the application is open so that modifications can be done without major effort or code change. Status update information will be delivered by various systems in an asynchronous fashion. For example, although a trade is input before being confirmed, CMM might get the confirmation status before the input status. In such a case, the status does not revert from confirmed to input. The status codes are applied in logical configurable sequence. 7.3.3. CMM - Partial Settlement The nature of the transactions involving eligible assets requires that CMM is capable of supporting partial settlement of market transactions. In support of this requirement, CMM provides transaction-splitting functionality and automated one-to-many matching functionality. 7.3.4. CMM - Status Change Actions Each status change can generate a specific action. The actions can be one or several of the following: • Sending a screen or e-mail notification based on the type of status change (for instance, if collateral withdrawal is declined by the liquidity provider). • Recalculation of the positions. 7.3.5. CMM - Collateral Positions Position balances will be used for tracking the projected and actual collateral and corresponding asset pledged balances. The positions will be affected in real-time during the life cycle of each event. For collateral positions, transactions are aggregated based on the issue, depository, pledged channel, and entity along with specific transaction value date and current status. Selection of positions and transactions is determined by the following: • Issue • Currency 81 Workflow Monitoring and Position-Keeping Functionality • Channel • Nominated branch • Asset Type • Depository • Eligibility rating of the issue against a Channel • Liquidity rating of the issue • Current status On any view of aggregated data, you can drill down to the detail components that make up the aggregated position. The following table summarizes how positions are directly affected by collateral transactions. Opening Balances are determined from the depository statement; or via feed from existing securities processing systems; or by rolling the EOD Calculated Actual Free Balance, Other Use, and Available Pledge Value figures forward to the new business day. Position Description Opening Balance The opening balance for an account; an individual security within a specific depository. Usually taken from an overnight batch feed or depository statement. It may be updated for back valued transactions. Inquiries will indicate that the balance has been adjusted and allow drill down to the movements. Opening Pledged The opening balance pledged to a Channel (Central Bank, Clearing system, etc.) at start of day (last EOD). Actual Free The net value of securities movements in and out that have been confirmed as settled. Does not include amounts pledged. Other Use The value of eligible assets used for a purpose other than liquidity provision (for example, tender credits and ‘specials’). Actual Pledged The value of collateral acknowledged as pledged. Booked Free Net value of Expected Movements resulting from trades that have been entered into the system but not yet match-confirmed. Expected Free Net value of Expected Movements confirmed with the counterparty. Expected Pledged The net value of Expected Movements representing requests to pledge or withdraw collateral that have not yet been confirmed by the liquidity provider or their depository agent. Several values in the Collateral Position inquiries are calculated from the above positions. They are: 82 Workflow Monitoring and Position-Keeping Functionality Collateral Values How the Values are Calculated Calculated Actual Pledged Balance = Opening Pledged Balance +/- Actual Pledged Movements Unencumbered Balance = Calculated Actual Free Balance – Calculated Actual Pledged Balance Forecast Unencumbered Bal- = Unencumbered Balance +/- Booked Free +/- Expected Free +/- Exance pected Pledged Potential Pledge Value = Forecast Unencumbered Balance x Adjusted All-In Rate Actual Pledged Balance = the sum of Opening Pledged Balance and Actual Pledged organized by Channel, Owner Entity and Responsible Unit. As in LMS, rules are used configure how the above balances should be determined from Transaction Type and Status combinations. 7.3.6. CMM - Projected Positions Projected positions are of interest for liquidity modeling, but have little bearing on intraday activities. CMM records prospective movements as they are received from the source systems. CMM also records projected events for issue and transaction maturities. The net result is a snapshot of available securities and their prospective availability and cash flows. All securities that can be considered for liquidity purposes are available to support liquidity forecasting and stress reporting. 7.3.7. CMM - Decision Support CMM will provide the ability to monitor, report, and view information in real time to facilitate the management of collateral and securities positions. Note Real time means positions are updated within 2-5 seconds of receipt of transactions or events by the system. These are database updates; CMM will not provide Publish/Subscribe outputs to users except through the standard Alert functionality described earlier. The system will provide standard views and Liquidity Insight Module capabilities. 7.3.8. CMM - Standard Position Views Some of the standard views include: • Currency Collateral Position • Collateral Position Detail • Currency Collateral Position Summary • Depository Detail Position 83 Workflow Monitoring and Position-Keeping Functionality • Depository Collateral Position • Issue Details Position • Projected Collateral Summary • Collateral Pledged to Channel 7.3.9. CMM - Custom Views The system will provide aggregated and detailed views of the bank’s collateral positions. These positions are built based upon attributes of the events such as issue, depository, clearing channels, and so on. The following aggregated views (positions) will also be possible: • Branch/Entity that acquired the security • Asset Type • Status • Issue Liquidity rating • Date • Currency • Groups of the above (for example, TradingDesk) These nonstandard aggregated views could be supplied via the Liquidity Insight Module of LMS. 7.3.10. CMM - Standard Transaction Inquiries The following are standard transaction inquiries: • Collateral Transaction Manager • Collateral Event Manager • Collateral Transaction Summary For transaction inquiries, the selection criteria allow selection by currency, clearing channel, issue, bank unit, date, time, event status, or combinations of the criteria. After you select a group of transactions, you can export the result to an Excel file for further analysis or aggregation. 84