Messages/payments are received from the different sources in different formats and through different channels like MQ, connect Direct
The received messages are parsed and stored in the database for processing.
In case there is any issue while parsing the file, technical alert must be generated and NAK must be sent to the sending channel
which E.g. MT101 message (SWIFT MT format) is received. The contents of the message are parsed as per the format and data is copied for different attributes and stored in database. In case the message file does not follow the prescribed format, it may result in error while parsing at specific position.
Step: Validation Check:
Before processing the message, validations are performed by the system
Each bank has their own set of Business Rules
In case of validation failure, the payment message is put in a queue where user can perform action on it. e.g. Repair, Reject, Approve etc.
After repair, the payment will be pushed back in the flow.
Types of Validations:
Format Level validations
Business Level validations
Format level validations are generally driven by SWIFT format.
Step: Auto Enrichment:
Automatically enriches information of the payment message to ensure that the message processing is STP
E.g. A payment message may have Name and Address of the Bank instead of Bank Identification Code (BIC). Auto-enrichment process looks up the database to replace the Name and Address information with proper BIC.
Other kind of enrichments are also done so that the message processing is STP
Step: Risk Filter:
A service for the bank to detect and hold transactions when facing external risk.
Risk filters are defined by the bank for safety reasons or to meet regulatory/legal requirements.
Allows a user to setup filters that detect and hold payments by matching the risk filter criteria with the payment properties.
Risk Filters are used to deliberately interrupt the processing of message which match the risk filter criteria.
The stopped payments will reside in a particular queue and can be released into the flow later by user.
User can indicate what the outcome of a hit should be (approval/reject). E.g. A bank user can create a Risk Filter to stop all payments that are being sent to Lehman
Step: Debit Party Identification:
Identifies the debit party in the payment message.
The payment could have traversed multiple banks before reaching a particular bank in the message flow.
Based on the route taken by the payment, Debit Party for this bank may change.
The bank checks the debit chain present in the message and identifies the Debit Party and Debit Party Account.
Step: Credit Party Identification:
Identifies the credit party in the payment message.
Credit Party is identified from the information given in the message.
Based on the Credit Party identified, the payment message will be routed.
In case the credit party account is present in bank’s book (on-us payment), no message will be sent out.
Step: Code Word Check:
Code words instruct a party in the payment chain to execute a certain action.
Each code word has a specific meaning which can be industry wide recognized or specific between 2 Banks.
Code word can be:
Defined by SWIFT
Imposed by industry practice
Bilateral agreed code words (between two banks)
There can be specific rules in each bank for code word processing and based on the code word(s) present in the incoming message, different actions may be taken on the message.
Code words are generally used in fields 23B, 23E, 26T, 70, 72 in SWIFT MT message.
E.g. CHQB (Pay beneficiary customer only by cheque). The code word ‘CHQB’ instructs the instructed agent (Credit party’s agent) to create a bank cheque to pay the beneficiary instead of crediting his account.
Routing means deciding the path which the payment will take to reach the destination account (Credit Party Account).
The system will try and find out the cheapest and quickest method to reach destination using routing rules that are configured within the system.
The routing rule determines the participant (external party/application) to which a transaction must be routed, based on the routing criteria defined in the rule.
The routing criteria can be defined based on various parameters of the payment message, like currency, settlement date, settlement amount etc.
In case multiple routing rules match for a payment message, the routing rule with lowest order of usage will be picked and payment message will be routed using that routing rule.
Step: Disposition Check:
The Disposition Check centralizes the validations that can be performed on accounts (debit and/or credit).
This service validates the accounts that need to be debited or credited in the flows.
Disposition Check also checks if Account Currency is present in the payment message and whether the currency is valid.
Following validations are part of Disposition Check:
Account Existence Check
Account Currency Check
Account Balance (Debit Account only)
Account Status (Activated/Deactivated)
Amount charged for providing payment services to, amongst others, customers and other financial institutions.
Charge bearer OUR, BEN, SHA : Indicates which party/parties will bear the charges
OUR : Charges are to be borne by the debit party.
BEN : Charges are to be borne by the credit party.
SHA : Charges will be shared by both debit and credit party.
There can be various kind of charges like – Repair Charge, Currency Conversion Charge, International Credit Transfer Charge etc.
Charges are determined based on the charge mechanism used. The rules to decide which charge mechanism to use, can be customized.
E.g. OUR (prepaid): The debit party’s agent calculates charges for self and for the next agent in the chain. He charges the customer for the total amount of charges. The charges due to the next agent are included in the settlement amount.
Step: Forex Conversion:
This service converts an amount expressed in one currency to the equivalent amount in another currency.
In case the payment message currency is different than the local bank currency (also known as Base currency), system will try to change the payment message amount into the local currency equivalent.
In order to do so, the system will use the exchange rate between the local currency and the payment currency.
Exchange rates are generally specified with buy, sell and mid rates.
Depending upon the scenario, buy rate or sell rate will be used by the system.
This service checks if the settlement date/time is in future and stores the future dated payment messages in the system.
The purpose of the Warehousing Service is to keep Instructions or Transactions in the system until they are to be released.
Payment messages can be determined for warehousing based on the following conditions:
The settlement date of the payment message is future dated, i.e. after the current date.
The payment message processing time is past the cut-off time for the day.
The system calculates the EDWART (Expected De-warehouse Time) for these messages, i.e. the date/time when the messages will be released for processing.
Once released, the messages get re-processed in the system and move to completion.
Note that the actual processing date may be different from settlement date.
Step: Accounting Entries:
Accounting entries are debit and credit balanced postings.
The generation of accounting entries is triggered by events invoked from the flow.
Accounting Scheme specifies which accounting entries have to be created for a certain event based on the information of the payment, a list of internal accounts and fixed values.
Most of the times, the core accounting system is not part of payment processing engine.
Step: Format and Post Message:
Once the processing is complete, the system sends out the outgoing message (if required).
The outgoing message is sent in a format which the receiver can understand. E.g. SWIFT format or any other bilaterally agreed format.
Formatter is a component which reads the relevant data internal data model/ database, transforms it in agreed format and creates a payment message (outgoing).
Once the payment message is posted/submitted, the system can be configured to receive Ack/NAK for the message.
GlobalSQA is one-stop solution to all your QA needs. Whatever your testing needs are, we have a solution. We provide solutions for all sorts of functional and non-functional testing as well as automation testing.