Integrating Payment Messages and Statements

The system allows integrating incoming MT103, pacs.008.001, MT202, pacs.009.001, MT202COV, MT204, MT205, MT205COV, MT210, MT900, MT910, camt.054 (camt054) messages and reconciling the incoming messages with Calypso transfers. The process is described below.

The system also allows integrating incoming MT940, MT942, MT950, MT970, camt.053 (camt053), camt.004 (camt004) and reconciling the incoming statement entries with Calypso transfers. The configuration is described below.

For pacs.008.001, pacs.009.001 integration, see MX Payment Messages Integration for details.

 

1. Setup Requirements

 

1.1 Environment Property

You need to set the following environment property:

SPLIT_CASH_STATEMENT = True

It splits every MT940/MT950 message into sub-statements. Each sub-statement representing individual financial transactions.

 

1.2 Processing Org Attributes

Set the following legal entity attributes on the processing organization as needed:

 

Fields	Description
CASH_MANAGEMENT	Set to true for advanced checks, or false otherwise. Advanced Checks When set to true, the system will perform specific prerequisite checks before processing an incoming statement MT940/MT950/camt053. These prerequisite checks are the following: • Check if all start-balances match the previous end-balances. • Check that all intermediate balances for an account are matching (Tag 60M/62M for a n-page statement). • Check that opening + movements = closing balance. • Check statement completeness and order (number of pages and existence of Tag 62F). • Check if all accounts exist in MT940 and vice-versa. • Check if date of end balance is not in the future. • Check if there is only one end-balance (and so MT940) per day. When set to true, you will need to run two scheduled task to integrate and process incoming MT940/MT950/camt053: first MESSAGE_MATCHING to save the incoming MT940/MT950/camt053 globally as a BO Message into the system, then INC_CASH_STATEMENT to run the checks and process the incoming MT950/camt053. When set to true, only statements marked as Valid are processed into the system. If one at least of the checks failed, the system raises a Process Status exception type StatementIntegration and stops the process. The user will have to check into the ProcessStatus report to know what check has failed and rerun the integration. No Check When set to false, the system will not perform any specific check and will process all statements MT940/MT950/camt053 as they come. In that mode, you will only need to run MESSAGE_MATCHING.
DEFAULT_BOOK	Default Book used by the system when creating a missing movement (Simple Transfer) from the "Match with Creation" function available in the Matching Manager.
DEFAULT_CPTY	Default Counterparty used by the system when creating a missing movement (Simple Transfer) from the "Match with Creation" function available in the Matching Manager.

 

1.3 Domain Values

Make sure the following domain values are set.

 

Domain "incomingType"

•

Value = MT103, Comment = INC_MT103

•

Value = MT202, Comment = INC_MT202

•

Value = MT204, Comment = INC_MT204

•

Value = MT205, Comment = INC_MT205

•

Value = MT210, Comment = INC_MT210

•

Value = MT900, Comment = INC_MT900

•

Value = MT910, Comment = INC_MT910

•

Value = MT940, Comment = INC_MT940

•

Value = MT942, Comment = INC_MT942

•

Value = MT950, Comment = INC_MT950

•

Value = CAMT053, Comment = INC_CAMT053

•

Value = CAMT054, Comment = INC_CAMT054

•

Value = CAMT004, Comment = INC_CAMT054

 

Domain "Swift.UserHeader.Service Identifier.<currency>"

Settlement platforms such as Target need to have a special logic to retrieve the GL Account. The settlement platform is the value of the Swift header's block 3 tag 103.

The domain "Swift.UserHeader.Service Identifier.<currency>" defines the list of supported service codes in Tag 103 of Swift header's block 3.

For example, create the domain "Swift.UserHeader.Service Identifier.EUR" for incoming EUR MT103/MT202 with the values:

•

Value = EBA

•

Value = STC

•

Value = TGT

 

Domain "IncomingSwiftTrade"

In order for incoming amend or cancel messages to be linked to the original message that they are amending/canceling, the respective message types need to be added to the domain "IncomingSwiftTrade". If a message type is not in IncomingSwiftTrade, when receiving an AMEND message for that message type, the matching framework will not attempt to un-match the original message which the AMEND is replacing.

Value = CAMT053

 

Domain "MX.Templates"

•

Value = CAMT053

 

Domain "ExternalMessageField.MessageMapper"

•

Value = CAMT053

•

Value = CAMT054

 

1.4 Settlement Account

The account where the processing organization receives and processes MT103/MT202/MT204/MT205/MT210/MT900/MT910/camt054 (and MT940/MT942/MT950/camt053) messages is configured as a standard SETTLE account for that specific Processing Organization, Currency and Agent.

The account must be attached to the processing org's settlement instructions.

The name of the account can be generic, for example "PO@AGENT-CCY".

 

Account Attributes

Set the following account attributes.

 

XferAgentAccount - The system stores the value of Tag 25 used by the Agent when sending intraday MT900/MT910/camt054 and T+1 MT940/MT950/camt053 in this account attribute.

 

Platform.<service code>

For the service codes defined in domain "Swift.UserHeader.Service Identifier.<currency>", you also need to set the account attributes "Platform.<service code>" to True to map the Tag 103 value of the block 3 of the incoming MT202/103.

For example, in domain "SwiftUserHeader.Service Identifier.EUR" we have the values EBA, STC, and TGT. So you need to create the account attributes: "Platform.EBA", "Platform.STC", and "Platform.TGT".

For camt053 / camt054 integration, it should be "Platform.<jurisdiction>".

 

 

When multiple accounts have account attribute “Platform.TGT = true”, the system needs to use the account with account attribute "Addressee11carBIC = <Receiver BIC minus ninth character>".

Example: Receiver BIC = NATXFRPPAMAR, Addressee11carBIC must be set to NATXFRPPMAR (it should not include the ninth character).

 

IgnoreDuplicateStatement - Applies to camt053 messages only.

In order to process incoming camt053 messages that contain multiple statements with same statement id, you need to set account attribute IgnoreDuplicateStatement = true.

Alternatively, you can use the domain name "camt053DuplicateStatement" with value allowDuplicate and comment true as shown in snapshot below:

The account attribute, if set, takes precedence over the domain value.

 

 

 

Incoming Statement Configuration

Settlement accounts are taken into account by the reconciliation process only if an incoming statement configuration is attached to the account.

To add an incoming statement configuration, select the Statements panel, and add a statement configuration of type "Incoming".

The frequency is used to determine when we expect an incoming MT940/MT950/camt053 for this account. The system does not process an incoming MT940/MT950/camt053 if the frequency does not expect such a statement for a specific date; inversely, the system raises an exception in the ProcessStatus report if a statement expected by the date rule is not received.

The incoming statement configuration also allows specifying the following options.

 

Options	Description
Initialize with Statement Message (MT940/MT950/MT970)	If not checked, there is no creation of an EXTERNAL inventory position. If checked, you have two options: • When "Booked Funds (tag 62F)" is checked, the system uses the balance amount as confirmed in the statement MT940/MT950/camt053 or 970 tag 62F to save "on a daily basis" an EXTERNAL-BANK CONFIRMED-SETTLE DATE inventory position. • When "Available Funds (tag 64)" is checked, the system uses the balance amount as confirmed in the statement MT940/MT950/camt053 or 970 tag 62F to save "on a daily basis" an EXTERNAL-BANK CONFIRMED-AVAILABLE DATE inventory position.
Update with Settlement Confirmation Message (MT900/MT910/ MT942/camt.054)	If not checked, incoming MT900/MT910/MT942/camt054 are only used to reconcile Calypso transfers. If selected, the same incoming MT900/MT910/MT942/camt054 are used to reconcile Calypso transfers and to compute an EXTERNAL/BANK CONFIRMED/SETTLED DATE inventory position in real-time. Combined with the initialization mode from the statement, this allows computing in real-time into the system the balance of the account as confirmed by the bank, taking into account only movements which are confirmed (whether reconciled or not)
Create BOCashSettlement from the Statement Message (MT940/MT950/MT970)	If checked, the system will create a specific trade on a product type = BOCashSettlement. If checked, a BOCashSettlement trade is created per statement: • Transfers associated with that trade are aggregated by value date (1 transfer per value date). • Transfers associated with that trade are of type EXTERNAL and only create an EXTERNAL-ACTUAL-SETTLE DATE position. • This option must be used when you want to recompute the external balance per value date and not per booking date as confirmed in Tag 62F or 64. This is particularly useful to calculate interest bearing trades using the exact same value date balance as the bank to check the amount.

 

Define the Processing Organization and Bank/Agent SWIFT Codes (LE Contact)

To be able to map an incoming message, you need to setup the related SWIFT Codes for the Processing Organization and Agent/Bank. As we reconcile outgoing SWIFT Messages, block 1 identifies the Receiver (Processing Organization) and block 2 the Sender (Bank/Agent). Thus, to be able to process the incoming messages you need to set in the LE Contact Window the SWIFT Address of the Processing Organization (to map block 1 swift address of the message receiver), and the SWIFT Address of the Agent (to map block 2 swift address of the message sender).

 

The LE Contact must be defined with Contact Type = ALL by default.

 

You can use another contact type for MT9xx and MT202 integration.

You need to add the contact type you want to use to the domain “MappingIncomingWithContact” (it applies to both the PO and the Agent):

Value = <message type>

Comment = <LE Contact type to be used to lookup the GL account>

Example:

Value = MT950

Comment = Settlement

If there is no contact with this contact type, the first contact found is used.

 

The logic to determine which account is impacted for a specific incoming message is the same for MT900/MT910 and MT940/MT950. We look for a unique account belonging to the processing organization which has a BIC Code = Block 1 BIC at the Agent = BIC Sender for the Account Number listed in Tag 25 and stored as XferAgentAccount account attribute for that Processing Organization's Agent.

In case environment property LOOK_PARENT_CONTACT = true, if the PO of the incoming message with proper BIC Code is a parent PO, then we look at accounts associated with children PO for which XferAgentAccount = Tag 25 of MT900/MT910 or MT940/MT950 to set the proper PO.

If the PO’s agent has legal entity attribute MultipleAccountName = true, the system will look up multiple accounts (defined in "XferAgentAccount.1", "XferAgenAccount.2", ..., XferAgentAccount.9"), not just XferAgentAccount.

If the currency of the message is different from the currency of the account it will check if it matches the corresponding ISO currency.

The logic is slightly different for incoming MT103/MT202/MT204/MT205/MT210 where we only consider the specific value set in Tag 103 of the Header/Block3 and map it with the Platform attribute of the account.

 

For camt053/camt054 messages, the identifiers are taken from the following tags.

The Incoming Linked Message Identifier is linked to the outgoing Message Identifier.

See MX Payment Messages Generation for information on setting up those identifiers.

Message Attributes	CAMT.054 Path
BusinessMessageIdentifier	From Business Header: field BizMsgIdr
LinkedInstructionId	/Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/NtryDtls/TxDtls/Refs/InstrId
LinkedEndToEndId	/Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/NtryDtls/TxDtls/Refs/EndToEndId
LinkedUETR	/Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/NtryDtls/TxDtls/Refs/UETR
LinkedSettlementAmount	/Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/Amt
LinkedSettlementAmountCcy	/Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/Amt
LinkedSettlementDate	/Document/BkToCstmrDbtCdtNtfctn/NtFctn/Ntry/ValDt/Dt OR /Document/BkToCstmrDbtCdtNtfctn/NtFctn/Ntry/ValDt/DtTm
AccountId	/Document/Ntfctn/Acct/Id/Othr/Id OR /Document/Ntfctn/Acct/Id/IBAN based on SDI attributes SDI Attributes IBAN.Agent, IBAN.Intermediary
DrCrIndicator	/Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/CdtDbtInd
InstructingAgentBIC	/Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/NtryDtls/TxDtls/RltdAgts/InstgAgt/FinInstnId/BICFI
InstructedAgentBIC	Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/NtryDtls/TxDtls/RltdAgts/InstdAgt/FinInstnId/BICFI
NtryStatus	Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/Sts/Cd
Money Amount	/Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/Amt is mapped with tag 32A (in context : MT900 & 910). For +/- in the below tag /Document/BkToCstmrDbtCdtNtfctn/Ntfctn/Ntry/CdtDbtInd - If the Debit then it would be - - If Credit then it would be +

 

Setup Example

An example is presented below for a standard bank account for the processing organization PARENT_COMPANY (Swift is PARNTCPY) with the agent BARCLAYS BANK PLC (BARCGB22) second block displays the Account Statement Config:

 

1.5 Settlement Instructions

Each processing organization bank account is attached to a SDI for the Role = Processing Organization and a SETTLE Method = SWIFT (for instance).

Below an example for the standard account of the processing organization PARENT_COMPANY with the agent BARCLAYS BK PLC:

 

1.6 Incoming Intraday Message Workflow

Define the incoming workflow for intraday reconciliation as shown below for incoming MT900 using Configuration > Workflow > Workflow Configuration from the Calypso Navigator.

All intraday messages (incoming MT103/MT202/MT204/MT205/MT210/MT900/MT910/camt054) follow the same workflow.

 

1.7 Incoming Statement Message Workflow

Define the incoming workflow for T+1 reconciliation as shown below for incoming statements using Configuration > Workflow > Workflow Configuration from the Calypso Navigator.

All T+1 incoming statements (incoming MT940/MT942/MT950/MT970/camt053) follow the same workflow.

The MT942 is saved as a statement and immediately split into sub-statements as soon as it is integrated into the system. Only the sub-statements are eligible for matching with the related transfer. All pending incoming MT942 sub-statements will be shown in the matching monitor to be reconciled manually with 1 or n transfers.

 

Simple Workflow

The workflow presented below can be used when processing incoming statements without prerequisite checks (scheduled task MESSAGE_MATCHING only + Processing Organization Attribute CASH_MANAGEMENT = false).

 

Static Data Filter Statement

 

Static Data Filter NotStatement

 

Static Data Filter SubStatement Nostro

 

Advanced Check Workflow

If you are working with prerequisite checks before processing the incoming statements (scheduled tasks MESSAGE_MATCHING and INC_CASH_STATEMENT + Processing Organization Attributes CASH_MANAGEMENT = true), you will need additional transitions to process the statement versus substatements created for each entry.

Specific transitions are needed to put the statement message into specific status depending on the result of the prerequisite checks. These actions (PROCESS/UNPROCESS) in the workflow below are applied by the scheduled task INC_CASH_STATEMENT.

 

INC_CAMT053 Workflow

 

1.8 Outgoing Message Workflow

For outgoing payment/receipt messages sent by Calypso, you will need to add the following transition / workflow rule to be able to handle the matching on reference:

 

1.9 Transfer Workflow

The transfer workflow presented below is only an example to be used as a starting point. Clients must then adjust based on their business process, especially in terms of manual and automatic write-off.

 

Static Data Filter WriteOff

This Static Data Filter allows automatically triggering the write off transfers when we are below the automatic tolerance (if set).

 

1.10 Attributes

Transfer attributes:

•

CYSettleRef - Tag 21 of the MT103/MT202 sent by Calypso for reference matching with confirmation of debit sent by the correspondent bank.

Tag 20 of incoming message (when using message rule AddTransferBusinessReference), or message attribute REF_PO (if set), or Message ID otherwise.

•

MatchedWith - Populated by the matching process: message id matched with the transfer.

 

Message attributes:

•

PORef - Reference of the message sent by Calypso and confirmed by the agent.

•

MatchedWith - Populated by the matching process; transfer id matched with the incoming message.

•

AgentRef - Tag20 of the incoming MT900/MT910.

 

The following matchable object attributes are stored to process the cutoff of the intraday matching:

•

Expected Cutoff - Expected date for the next cutoff. This allows integrating back value movement into the matching, even when previous cutoff/statement for that date has been received.

•

Account Lastest CutOff - Last statement received and processed for that account.

 

Matching Transfer Attributes to Swift Message Fields Tag 86 and Tag 61

Tag 86 of a MT940 - Information to Account Owner

Tag 61 of a MT940 or MT950 - Statement Line.Supplementary Details

The following domain have been added: “MatchingKeyFromXferAttr.Information_to_Account_Owner” and “MatchingKeyFromXferAttr.Statement_Line.Supplementary_Details”.

They should contain the corresponding transfer attributes to be used. They must belong to the domain “XferAttributes”.

The transfer attributes should also be defined as trade keywords and should be added to the domain “PropagateTradeKeyword”.

Matching keys have been added for these attributes:

•

Information to Account Owner

•

Statement Line.Supplementary Details

The tolerance rule “Contains” should be added to the domain “MatchingContext.Field.Tolerance” and can be selected on the new matching keys.

It checks if the Incoming Matching key contains the Outgoing Matching Key or if the Outgoing Matching Key contains the Incoming Matching key.

 

1.11 Global Payments Innovation (GPI) Fields

The fields 111 (Service Type Identifier) and 121 (Unique End-to-End Transaction Reference (UETR)) can be added to header block 3 based on the following configuration.

The message types for which the fields 111 and 121 should be added are defined in the domain “SWIFT.Templates.GPI”.

By default, it contains the following messages: MT103, MT202, MT202COV, MT205, MT205COV.

 

You also need to set the following Processing Org attribute:

SWIFT_GPI – true to populate field 111 (it is false by default).

 

Field 111 is populated with 001 by default or with the Comment specified for a given message in the domain “SWIFT.Templates.GPI” if any. You can also set Comment = NONE to not populate field 111 for that message.

 

Field 121 is populated with the UETR for outgoing messages and is set in the message attribute UETR for incoming messages.

If the agent cannot receive the UETR, set the following Agent attribute:

SWIFT_ExcludeUETR = true to remove the UETR from field 121.

 

1.12 Message Setup

To avoid issues with reference matching when doing a Match With Creation, you need to filter the generation of messages for a Simple Transfer created from the matching manager using the Match with Creation function.

This can be done by adding a static data filter on the message setup to avoid the generation of payment messages for simple transfer, as shown below:

 

Static Data Filter TradeSourceIsNull

 

1.13 Intraday Matching Context Definition

Define the matching context for intraday reconciliation using the Matching Context Definition window (menu action refdata.MatchingContextConfigurationWindow).

 

Intraday Matching Context - Scope

Define the Scope of the intraday matching context as shown below:

 

 

Intraday Matching Context - Matching

Define the Matching panel of the intraday matching context as shown below:

The actions are applied to both the incoming message and the outgoing transfer, hence they must be defined in the Incoming Message workflow and the Transfer workflow.

 

 

For each matching criteria selected in that panel, the user needs to define using the Usage cell if the criteria is used for All (automatic and manual matching), Automatic matching only, Manual matching only, or None.

For each matching criteria selected in that panel, the user needs to define the weight and any specific tolerance he would like to apply for that criteria.

The examples below are indicative only. You may want to use different rules/tolerances based on your business processes.

 

Settlement Amount (criteria must be cumulative to allow n to m matching). Tolerance can be of different Type (Percentage/Unit/UnitPerAmount and Currency. When using currency, the system allows using the LE Tolerance table to set different tolerance per currency, processing organization and correspondent/bank).

 

Settle Date

 

Ccy

 

GLAccount

 

POReference (PO reference is only used for payments)

 

Intraday Matching Context - Matching Options

Define the Matching Options panel of the intraday matching context as shown below:

 

Options	Description
Request Comment	Activate the Request Comment option when you want to make a user comment mandatory when a matching is performed manually from the matching manager.
Allow Match with Creation	Activate the Allow Match With Creation when you want to add the possibility for a user to create a missing movement into the system from an incoming message when choosing that menu in the matching manager. The system will create a Simple Xfer with the DEFAULT_BOOK and DEFAULT_CPTY set as attributes on the processing organization. Choose the Reversal Mode (when there is a difference of value date to reverse/new the flow from the matching manager). Choose the Auto Creation mode (the system will ask you to specify the default flow type) when you want to automatically create a missing movement from incoming messages.
Allow Partial Match	Activate the Allow Partial Match function (with Config Name = CashSettlement) when you want to allow a manual partial match. For example, Incoming Msg confirms USD 900,000.00 while you have a transfer for USD 1,000,000.00. You can manually partial match these two entries: It will settle USD 900,000.00 confirmed by the Agent and will Fail the remaining USD 100,000.00 that will remain as "item to reconcile" in the matching manager. Partial Match requires specific Transfer Workflow actions (PARTIAL_SETTLE) to work correctly. See workflow section for details. Activate the mode write off to create a specific flow for small differences going to a specific status to trigger specific postings/accounts. There again, refer to the Transfer Workflow section for additional actions required for that mode. The WriteOff Mode allows you to automatically write offs some small differences. The flow type is taken from domain “flowTypeWriteOff”.
Allow Same Side Matching	Activate the Same Side Match function when you want to allow the user to match n entries within the same category. We usually only activate that options for incoming messages. The system allows Same Side Match within several incoming messages if the global amount is zero.
Allow Investigation	Activate the Allow Investigation when you want to add the possibility for a user "from the matching manager" to mark an item to reconcile as "under investigation" and add a specific comment. Next user will be able to see the comment history and to act as this mode leave the item into the list of "pending reconciliation". The additional mode "Allow With Creation" allows to impact your balance for that amount without having to wait for the real correction of the trade from your front desk (creation of a specific Simple Transfer into the system).
Propagation	Activate the Propagation mode if you want to propagate (when your tolerance allows it) the real settlement amount and/or real settle date on the transfer when matching an incoming message with a transfer having a different date and/or value. Specific inventory position types will reflect these changes.

 

The manual actions proposed by the system in the matching manager are based on tolerance and matching options defined in the matching context when selecting incoming and outgoing objects.

 

Intraday Matching Context - Best Matching

Define the Best Matching panel of the intraday matching context as shown below:

 

Intraday Matching Context - Investigation

Define the Investigation panel of the intraday matching context as shown below:

 

Intraday Matching Context - More Options

Define the More Options panel of the intraday matching context as shown below:

Eligibility CutOff must be set on the intraday matching context to clean automatically un-reconciled items intraday once the statement for that specific account/date has been received and processed by the system.

 

Options	Description
Config Name	Select CashSettlement.
CutOff Time	Select the starting cutoff time - Format is 1500 (for 3pm); 1530 (for 3.30pm),
Frequency (Hour)	Select frequency when the system must automatically rerun the cutoff from the initial cutoff time (min is 1h).
TimeZone	Select the reference Time Zone.
EOD Context	Select the End of Day context linked to intraday (must be the one for MT940/MT950/MT970/camt053).
Run CutOff	Possibility to run manual cutoff from that screen.

 

1.14 camt054 Mathing Context

UETR is the supported matching key.

 

1.15 Statement Matching Context

To reconcile statements at T+1.

 

Statement Matching Context - Scope

Define the Scope of the T+1 matching context as shown below (we currently support MT940/MT950/MT970/camt053):

 

Statement Matching Context - Matching - Matching Options - Best Matching

Define these panels of the T+1 matching context with the same criteria/options as the intraday matching context.

 

Statement Matching Context - Investigation

Define the Investigation panel of the T+1 matching context as shown below:

 

Statement Matching Context - More Options

Define the More Options panel of the T+1 matching context as shown below:

 

1.16 Matching Manager Setup

You can monitor the progress of the integration process using the Matching Monitor (menu action reporting.MatchingUILauncher Matchable) - [NOTE: There is space before Matchable].

Define the matching manager templates for Intraday and statement matching contexts.

The system provides several views from the general Summary view of intraday and statement matching items.

Click to load matchable objects.

You can adjust the search criteria as needed.

 

To configure the system, you need to initialize the categories with incoming and outgoing items and then select the view to drill-down to the default template. Then, you can define for each report the default template.

The Investigate panel provides a summary view of un-reconciled incoming sub-statements in the top-part and un-reconciled calypso transfers in the bottom-part. This is the default view used to reconcile incoming messages and outgoing transfers.

Additional views are available for additional investigation or action:

•

The Linked panel provides a summary view of matched/reconciled items with the possibility to unmatch wrongly reconciled items.

•

The Details panel provides a simple view of a specific matching category. When selecting unmatched items (=transfers not reconciled), the system allows to use the Best Match option and provides a list of possible messages for a specific payment with rating and matching score.

 

Matching Categories

Different matching status codes are used by the system to categorize incoming messages and outgoing transfers based on their reconciliation status.

•

Incoming Message Matchable Status

–

Alleged = Identifies all incoming messages waiting for reconciliation.

–

Notification (Orphan) = Identifies all incoming MT103/MT202/MT204/MT205/MT210 for which the system was not able to identify the account (For example, copy of a MT202 received from the counterparty). These messages are integrated for information purposes and can be attached to any specific transfer for audit/investigation.

–

Notification = Identifies all notifications when attached to a transfer (they are considered as processed).

•

Outgoing Transfer Matchable Status

Unmatched = Identifies all calypso transfer waiting for reconciliation.

•

Incoming and Outgoing Matchable Status

–

Matched = Identifies all reconciled items.

–

Canceled = Identifies all items not eligible to matching anymore

 

All MT210 are considered notifications. The Nostro lookup is done as follows:

•

Agent = Tag 56, or Tag 52a if Tag 56 is empty.

•

Processing Org = Receiver of the Swift

•

Currency = Tag 32

 

Investigate View Setup

You can click Investigate to get the default view of all "packed" un-reconciled items. You can then, split and filter your table using the Split and Filter functions available in that panel.

Without panel split and filter all unmatched items are mixed as shown below:

To configure the default layout of that screen, press the split panel icon . This will display the "incoming" un-reconciled items at the top and the "outgoing" un-reconciled items at the bottom (as shown below).

Then define the filter as needed.

You can click the  icon to show the filter on the Investigate panel. Please note that the Matching Manager is using a docking framework, and as such, can be configured as desired by the end-user. Thus, the view displayed here can be entirely customized by the user.

It is recommended to save your configuration as a template using Report > Save As Template, and make this template the default template using Report > Set Default Template.

 

Contextual Action Buttons

Based on the configuration of the Matching Context options and the elements selected as incoming and outgoing, the system will propose the possible actions (Match, Same Side Match, Partial Match, Match with Creation, Attach).

Possible actions are the following (they are proposed by the system based on configuration and items selected in the Investigate panel):

•

Match

•

Match With Creation

•

Partial Match

•

Investigate

•

Attach

•

Force Match

The system allows matching m incoming message with n outgoing messages manually from the Matching Manager using tolerances.

 

Linked Panels

The Linked panel or Details panel of your Matching Manager allow seeing the matched items and undo the matching. The Details panel also allows doing a Best Match from unmatched transfers to propose the possible incoming message with a rating.

The system shows the category (Automatically Matched, Manually Matched, Manually Matched With Creation, Partially Matched) and the Matching couple (transfer/message).

You can use the Unmatch button to undo a matching from that screen.

 

Example for the Alleged category.

From the Alleged details, the user can select a message and click Potential Match. The system will then present the list of possible outgoing transfers with their score for that message.

 

You can also bring up the details of the Unmatched category. When you click Potential Match, the system will present the list of possible incoming messages with their score for that transfer.

 

2. Integration and Reconciliation of Incoming Messages

In order to start the integration and reconciliation process, the following engines must be running:

•

Transfer Engine

•

Message Engine

•

Inventory Engine

•

Matching Engine

•

MatchableBuilder Engine

 

To import incoming payment messages, run the scheduled task MESSAGE_MATCHING.

 

Once imported, the incoming messages are saved to the Calypso database as a standard bo_message, then go through the matching process.

Automatic matching will be performed if applicable. For the unmatched messages, you will need to go to the Matching Manager to manually match messages and transfers (menu action reporting.MatchingUILauncher Matchable) - [NOTE: There is space before Matchable].

The system supports two modes for the integration of statements:

•

No Check Mode - No check on statement format and completeness (PO attribute CASH_MANAGEMENT = false). In that mode, you only need to run the MESSAGE_MATCHING scheduled task to integrate and process incoming statements. Once saved as incoming statements, the system splits the global message (identified with Msg Attribute = Statement) into sub-statements (identified with Msg Attribute = "Substatement.Nostro") and each sub-statement is then processed by the matchable builder and matching engines for reconciliation.

•

Prerequisite Check Mode - Check on statement format and completeness (PO attribute CASH_MANAGEMENT = true). In that mode, you need to run the MESSAGE_MATCHING scheduled task to integrate the statement and INC_CASH_STATEMENT to process the incoming statements. Once saved as incoming statement by MESSAGE_MATCHING, the INC_CASH_STATEMENT splits the global message (identified with Msg Attribute = Statement) into sub-statements (identified with Msg Attribute = "Substatement.Nostro") and each sub-statement is then processed by the matchable builder and matching engines for reconciliation. The split process, with that mode, only occurs if all prerequisite checks on statement format and completeness are validated. In that case, the system throws a valid Statement Integration process status. If one check fails, split of statement is not performed and an invalid Statement Integration process status is generated. The statement is blocked in a certain status and manual action must be taken to proceed. This mode requires additional message workflow actions as specified in workflow configuration section.

 

The Process Status report displays exceptions/errors blocking all or part of the statement integration and intraday cleaning process.

See Process Status Report for details.

 

2.1 Scheduled Task MESSAGE_MATCHING

The import of the incoming message files is done through the MESSAGE_MATCHING scheduled task.

This scheduled task is used to import all incoming messages (intraday matching MT103/MT202/MT204/MT205/MT210/MT900/MT910 and statements MT940/MT950/MT970/camt053) in batch mode.

 

Scheduled Task Attributes

•

Swift Message Delimiter - Enter the delimiter between messages in the text file as specified in the environment property CALYPSO_SWIFT_LINE_SEPARATOR (should be blank if the property is not used).

•

Swift File - Specify the Swift File Name (eg.20090325_BARC_0052.txt) to integrate one specific file. To integrate all incoming MTxxx, the user has to set the value *.txt on that field. The system will then try to save as "bo_message" all .txt files that are located under the InputDir.

•

InputDir - Specify the Swift File Path and Directory where txt files are saved.

•

File Rename - Select true/false. When set to true add a timestamp to the Swift File once processed.

•

Gateway/ExternalMessageType - If the default implementation for processing MT940 is not satisfying, the CashStatementHandlerFactory tries to retrieve a Handler respecting the order Gateway "ExternalMessageType" as specified in these attributes.

The MESSAGE_MATCHING scheduled task does not perform any validation; it only saves the incoming message as Calypso Messages.

 

2.2 Scheduled Task INC_CASH_STATEMENT

This scheduled task is only needed for the "prerequisite checks" mode. It is only when the PO Attribute CASH_MANAGEMENT is set to true that this mode is activated. This scheduled task is only processing statements (Intraday incoming messages only need MESSAGE_MATCHING to be processed).

In that mode, once the scheduled task MESSAGE_MATCHING is reported as successful, it is necessary to run the INC_CASH_STATEMENT scheduled task to process the incoming statements.

Thus, with the prerequisite check mode activated, the statement (MT940/MT950/MT970/camt053) integration process is a two-step process:

•

We first save the complete incoming statements using the MESSAGE_MATCHING.

•

We then check the consistency and completeness of these statements, split the MT940/MT950/MT970/camt053 into sub-statements by entry using the INC_CASH_STATEMENT.

Then, the matching process is performed by the matchable builder and matching engines.

 

For corporate cash management, the INC_CASH_STATEMENT execution is a two-step process. You only need step 1 otherwise.

 

Step 1 - Process Incoming Statements

•

Load all statement messages (initially saved by the MESSAGE_MATCHING) applying the "Statement statuses restriction" attribute for the scheduled task's Valuation Date (= Tag 62F statement date, or tag <Document><BkToCstmrStmt>/<Stmt>/<Bal>/<Tp>/<dt> for camt053).

•

Group the statement messages by GL (SETTLE) Account.

The correspondence between the MT940/MT950/MT970 Tag 25 for a specific Processing Organization (Receiver BIC) + Agent (Sender BIC) and the Calypso GL Account is done using the GL Account Attribute "XferAgentAccount" where we store the value of Tag 25.

For camt053 messages, the GL account is stored in tag <Document><BkToCstmrStmt>/<Stmt>/<Acct>/<Id>.

•

Check the Group consistency (Sequence Numbering/Intermediary Balances/Statement Opening Balance = Previous Statement Closing Balance, etc.).

•

Create Account Statement summarizing the group information.

•

Create Sub-Statement Messages (with specific types).

•

Create BOCashSettlement Trade for each valid statement.

•

Apply the "Valid/Invalid Statements Action" on Account Statement summarizing the group information:

–

INC_MT940/MT950/MT970/camt053 Message Workflow Valid Action is applied on complete and consistent grouped statements

–

INC_MT940/MT950/MT970/camt053 Message Workflow Invalid Action is applied on incomplete and/or inconsistent grouped statements

 

Step 2 - Exclude FORECAST Transfer Types

Corporate Cash Management only.

FORECAST transfer types must be excluded from the Cash Position for the Processing Organization Bank Accounts successfully processed in Step 1.

•

Load all simple transfer trades with transfer type = FORECAST and related transfers type FORECAST having a Settle Date <= Scheduled Task Valuation Date for the GL Accounts in the group applying the "Forecast statuses restriction" attribute.

•

Apply the "Forecast Action" set as attribute on the selected Simple Transfer trades type FORECAST and related transfers.

The "Forecast Action" is an action that must be added to your trade and transfer workflows (on transition VERIFIED - SUBSTITUTE- SUBSTITUTED for example).

•

This resulting status (SUBSTITUTED in our example) must be set in the transferCanceledStatus and ignoreTradeStatus to make the system treat them as a CANCEL and exclude transfers with that specific status from the inventory position. This also allows building specific trade and transfer reports including or excluding these forecasts.

 

Scheduled Task Attributes

These steps are driven by the attributes set on the INC_CASH_STATEMENT scheduled task.

•

GL Account Id - Specify the Processing Organization SETTLE account for which you want to run the process. If left blank, the process is run for all the processing organization SETTLE accounts initially saved by the MESSAGE_MATCHING scheduled task.

•

Statement statuses restriction - Specify the statement message status to take into account for the for the scheduled task's Valuation Date (= Tag62F statement date).

•

Valid Statements Action - Specify the statement workflow action to apply on complete and consistent grouped statements.

•

Invalid Statements Action - Specify the statement workflow action to apply on incomplete and inconsistent grouped statements.

•

Check Statements Exhaustivity - True or false. When set to true, the system reports "missing statements" as exceptions in the exception file (e.g. a statement is expected for a specific bank account according to the incoming statement configuration date rule but the related MT940 is not received). When set to false, the system only reports exceptions for received statements, without reporting missing statements (type missing page, wrong opening balance, etc.).

•

Forecast statuses restriction - Only applies to Corporate Cash Management - Specify the trade and transfer status to take into account to load the FORECAST trades/transfers. The system will load all Simple Transfer trades with type = FORECAST and related transfers type FORECAST which have a Settle Date <= Scheduled Task Valuation Date for that/these status(es) (eg. no restriction in the above example).

THIS IS NOT NEEDED AND MUST BE LEFT BLANK FOR STANDARD CASH MANAGEMENT

•

Forecast Action - Only applies to Corporate Cash Management - Specify the trade and transfer workflow action that the system must apply on the selected FORECAST trades and transfers (e.g. SUBSTITUTE trade and transfer action will be applied on FORECAST transfers and Simple Transfer Trades with Transfer Type = FORECAST in the above example). The "Forecast Action" is a trade and transfer action that must be added to your trade and transfer workflows (e.g. VERIFIED - SUBSTITUTE - SUBSTITUTED for this type of trader/transfer using SD Filters or Trade and Xfer workflow types). Then, one must add the resulting status in the domains "transferCanceledStatus" and "ignoreTradeStatus" to make the system treat that status as a CANCEL and, as such, exclude transfers with that specific status from inventory position.

THIS IS NOT NEEDED AND MUST BE LEFT BLANK FOR STANDARD CASH MANAGEMENT

•

Exception Report Format - The Scheduled Task generates an Exception report which allows having a summary of all the issues encountered during the processing. Define the format of that exception file in the "Exception Report Format" attribute. Available format include: excel, html, csv, pdf.

•

Email Exception Report to - This exception file can be sent by email. Specify the email address or alias using the "Email Exception Report to" attribute.

 

Prerequisite Checks performed by the INC_CASH_STATEMENT scheduled task

The consistency checks performed by the INC_CASH_STATEMENT scheduled task are the following.

•

Check if all start-balances match the previous end-balances.

•

Check that all intermediate balances for an account are matching (Tag 60M/62M for a n-page statement).

•

Check that opening + movements = closing balance.

•

Check statement completeness and order (number of pages and existence of Tag 62F).

•

Check if all accounts exist in MT940 and vice-versa.

•

Check if date of end balance is not in the future.

•

Check if there is only one end-balance (and so MT940) per day.