8.1.2 FX Confirmation Matching - Auto and Manual Matching Process

FX Confirmation Rule Maintenance

Rule maintenance screen is provided for maintaining confirmation rules. Auto matching of confirmation messages is done based on these rules.

The fields which are available in the confirmation rule maintenance screen for the Functional ID FXDCNFMT are:

Figure 8-4 Confirmation Rule Maintenance

Description of "Figure 8-4 Confirmation Rule Maintenance"

For information on fields, which is same as the product processor, refer to the below table.

Table 8-1 Confirmation Rule Maintenance - Field description

Field	Description
Rule Id	Specify the unique ID for a rule.
Rule Description	Specify the description for the specified rule ID.
Sequence Number	The system displays the sequence number. You can modify this. If there are multiple Rules, the processing for auto matching the messages will happen based on the sequence number in an ascending order.
Full Match	Check this box if the confirmation rule maintained is a Full Match Rule. It is mandatory to check all the above fields except the below-mentioned fields if the maintained rule is to as ‘Full Match’: Event Settlement for Receive Leg Settlement for Pay Leg AWI for Receive Leg AWI for Pay Leg Intermediary Receive Leg Intermediary Pay Leg Beneficiary Institution Pay Leg Common Reference You can maintain more than one rule as full match. The system verifies the message details with the contract details based on the confirmation rules maintained. If single contract details match with message details for a ‘Full match’ rule, then the message is marked as completely matched, and the contract is marked as confirmed.
Fields to be matched	You can enable the following fields to match the details of an incoming SWIFT confirmation message MT300 with an existing deal in Oracle BankingTreasury Management: Counterparty Booking Date Event Value Date Bought Currency Bought Amount Sold Currency Sold Amount Exchange Rate Settlement for Receive Leg Settlement for Pay Leg AWI for Receive Leg AWI for Pay Leg Intermediary Receive Leg Intermediary Pay Leg Beneficiary Institution Pay Leg Common Reference
Field to be Matched	If ‘Full Match’ is checked, then the following fields are mandatory: Counterparty Booking Date Value Date Bought Currency Bought Amount Sold Currency Sold Amount Exchange Rate If the outcome of a Full Match rule is satisfied with a single deal, then the system marks the message as Completely Matched and the deal as Confirmed. If multiple contracts match with a Full match rule, then the system marks the message as Partially Matched. Even if message and deal details are matched based on the listed fields in rule which marks the Full Match, the system marks the messages as Partially Matched. Manually match the partially matched messages.

Example for Multiple Confirmation Rules/Rule Class Maintenance

This topic describes about examples for Multiple Confirmation Rules/Rule Class Maintenance.

Assume that there is a set of three confirmation rules for the FX module. The characteristics of each of these rules are as follows:

Table 8-2 Rule Table

Field	Description
RULE_01	This is a full match type of a rule where it is indicated that the system should process the contract if the values in the FX contract should match with the following details of an uploaded message: Counterparty Booking Date Event Value Date Bought Currency Bought Amount Sold Currency Exchange Rate Settlement for Receive Leg Settlement for Pay Leg AWI for Receive Leg AWI for Pay Leg
RULE_02	Full Match, for the following fields: Counterparty Booking Date Event Value Date Bought Currency Bought Amount Sold Currency Exchange Rate
RULE_03	Partial Match for the following fields: Counterparty Receive leg settlement instructions Pay leg settlement instructions AWI Receive Leg AWI Pay Leg

While specifying the Rule Sequence it is maintained in the following order:

Table 8-3 Rules table

Sequence Number	Rule ID
1	RULE_01
2	RULE_02
3	RULE_03

As a result, each time FX messages are uploaded into FLEXCUBE from through SWIFT, the system tries to match the data available in the messages with existing unconfirmed FX contracts as per the sequence in which the rules have been maintained. Therefore, if the system is unsuccessful in finding full matches, it will compare the message with RULE_03 to look for a partial match. This pattern will continue until the details of the message match an existing contract. If the system is unsuccessful in finding a match, the message is marked with the status ‘Unmatched’. Users is able to view the details of the particular message in the Manual Matching Browser screen where you will also be allowed to perform a manual matching of messages with existing contracts.

Treasury Customer Address Maintenance

This topic describes about Treasury Customer Address Maintenance. This screen is viewed using the functional ID MSDTRCAD.

Figure 8-5 Treasury Customer Address Maintenance

Description of "Figure 8-5 Treasury Customer Address Maintenance"

• Auto matching of Confirmation Messages will happen only when the confirmation matching flag is checked for the combination of customer, branch, message type, module, location and media.

For information on fields refer to the MS User Manual, chapter 4 section 4.1.1 Maintaining Address at Customer (CIF) Level.

FX Confirmation Message Matching Screen

Confirmation Message matching with the Functional ID FXDMATCH provides querying matched/partial matched/unmatched message details. User can also do a manual match / un-match using this screen.

Figure 8-6 Confirmation Message Matching

Description of "Figure 8-6 Confirmation Message Matching"

For information on Confirmation Message Matching, refer to the FX user manual Chapter 3, section 3.9.

FXSMATCH- FX Confirmation Message Matching Summary

User can select an auto/manual match record from the summary screen.

The query criteria available is Match reference number, Record Status, Authorization Status, Message Reference, Contract reference number & Mode of Matching.

Mode of Matching can be Auto or Manual.

For more information, refer to the FX user guide chapter 3, section 3.9.6.

Auto Matching of FX Confirmation Messages

This topic describes about Auto Matching of FX Confirmation Message.

• System will match incoming confirmation messages with the outgoing based on rules maintained.
• Changes is made so that the upload activity in the incoming message browser will parse the message and upload it into an internal upload table, thus confirming that the format is correct. If this step is successful, the incoming browser will show the message as processed else the message is marked for repair with an error code, which indicated the format error.
• The auto confirmation batch will then use the data in the incoming message and execute the matching based on Confirmation rule set up.
• The auto-confirmation matching batch will use the rules in the sequence defined and attempt to match the messages to a contract for fully/partially matched cases
• The matching of the incoming confirmation message details with the deal details is done based on the matching required fields maintained for the confirmation rule.
• The processing is done sequentially based on the rule codes maintained for the confirmation class for FX module
• During the auto match processing, if the details of an incoming message are matched with a single existing deal in the system based on a Full Match rule, then confirmation is marked for the deal by triggering CONF event. The message is marked as ‘Completely Matched’.
• If multiple contracts are matched with a single message while processing a Full Match Rule, then the message is marked as Partially Matched.
• If the message is matched while processing according to a Rule code not checked for ‘Full Match’, then also message is marked as partially matched.
• Partially matched deals have to be manually matched by the user from Manual Matching screen.
• The below fields of the FX deals is matched against the message field values as per the existing logic in the system:

Table 8-4 Message Fields

MT 300 FX Confirmation Message field	FX Contract Field
82A	Counterparty BIC
30T	Booking Date
22A	Events
30V	Value Date
33B	Bought Currency
33B	Bought Amount
32B	Sold Currency
32B	Sold Amount
36	Deal rate
57a Settlement for Bought Leg	Settlement for Sold Leg
57a Settlement for Sold Leg	Settlement for Bought Leg
57a Account With Institution for Bought Leg	Account With Institution for Sold Leg
57a Account With Institution for Sold Leg	57a Account With Institution for Bought Leg
58a Beneficiary Institution Pay Leg	Branch BIC Code
22C	Common Reference
56A Intermediary Bought Leg	Intermediary Sold Leg
56A Intermediary Sold Leg	Intermediary Bought Leg

Party detail fields is matched based on BIC codes (Option A) only.

The list of contracts against a message in case of full/partial matches is stored and subsequently can be viewed from the “Manual Matching of Confirmation Messages” screen, henceforth further manual action can be taken to complete the confirmation process.

While doing an auto matching system will match an incoming message with details of latest outgoing confirmation message details of a contract.

To have Settlement Pay\ Receive field populated as 57A, the Account with institution should be of below format. Line one as account number and line 2 BIC

Whereas to have AWI Pay\ Receive leg populated as 57A, the Account with institution is below format. Line one as BIC, For example:-:57A:CHEMUS33

Eg-:57A:/309945-009

CHEMUS33

or

:57A://CH123456

CITIUS33