Session16- ISO20022 standard Message Implementation Knowledge Question Answer Phase1–33 to 36

 33. What data is to be provided in PaymentTypeInformation ?

 This mandatory field contains set of elements used to further specify the type of transaction. Type: This message item is composed of the following PaymentTypeInformation element(s):3

i) InstructionPriority Presence: 

[1..1] Definition: Indicator of the urgency or order of importance that the instructing party would like the instructed party to apply to the processing of the instruction. Data Type: Code The default priority assigned to every message is HIGH

ii) ServiceLevel

Presence: [0..1] Definition: Agreement under which or rules under which the transaction should be processed. Type: This message item is composed of one of the following ServiceLevel Choice element(s): 

 

 Proprietary Presence: [1..1] 

Definition: Specifies a pre-agreed service or level of service between the parties, as a proprietary code. For RTGS processing priority is in range 00 – 99. This field also contain the Transaction Type code (TTC) along with the priority value. TTC values will be used to differentiate the transactions within the same type of transaction. e.g. in the pacs.009 transaction message the MNSB Own account transfer and Interbank transaction will have different TTC values. Use: To be used for managing queues by sending bank before settlement. 

Data Type: Max35

Text Format: maxLength: 35:

For RTGS lower the number highest will be the priority. For Banks priority range is from 11 to 99. Priority from 00 to 10 is reserved for RBI. 

 [TTC=xxxx],[PRI=xx]  

iii) LocalInstrument

Presence: [1..1] Definition: User community specific instrument. Usage: This element is used to specify a local instrument, local clearing option and/or further qualify the service or service level. Type: This message item is composed of one of the following LocalInstrument2Choice element(s): 

Proprietary Presence: [1..1] 

Definition: Specifies the local instrument, as a proprietary code. Type of local instrument. 

For RTGS pacs.008 use: -- ‘RTGSFIToFICustomerCredit’ 

For RTGS, pacs.009 use: -- ‘RTGSFIToFICredit’ -- ‘RTGSOwnAccTransfer’ -- ‘RTGSNetSettlementXXzNN’ 

For Return Payment use: -- ‘RTGSPaymentReturn’ Data Type: Max35Text Format: maxLength: 35

iv) CategoryPurpose Presence: 

[1..1] Definition: Specifies the high level purpose of the instruction based on a set of pre-defined categories. Purpose of the Instrument. Payment purpose must be a value listed in ISO category purpose code Type: This message item is composed of one of the following CategoryPurpose Choice element(s):

Code Presence: [1..1] Definition: Category purpose, as published in an external category purpose code list. Data Type: ExternalCategoryPurpose1Code Format: maxLength: 4 minLength: 1 Default value: CASH 

FROM ISO 20022External Code list The following codes are available. CASH: CashManagementTransfer CORT: TradeSettlementPayment DIVI : Dividend GOVT: GovernmentPayment HEDG: Hedging INTC : IntraCompanyPayment INTE : Interest LOAN: Loan PENS: PensionPayment SALA: SalaryPayment SECU: Securities SSBE: SocialSecurityBenefit SUPP: SupplierPayment TAXS: TaxPayment TRAD: Trade TREA: TreasuryPayment VATX: ValueAddedTaxPayment WHLD: WithHolding

The generic code for the normal funds transfer may be 'CASH'. Example: CASH

34. How the funds are pushed and sweep back at the time of SOD (Start of Day) and EOD (End of Day) respectively? 

The message format used for balance sweeping is Pacs.009 MNSB transaction? a) For SOD: - one debit against the settlement account of RBI in amount equal to the sum of all credits - multiple credits against the settlement accounts of the Participants that have their balances initialized b) For EOD: - multiple debits against the settlement accounts of all Participants with a non-zero balance in NG-RTGS - one credit against the settlement account of RBI in amount equal to the sum of all debits Distinct TTC values are used for these two transactions For SOD the TTC value is 5050 whereas for EOD the TTC is 5051

 35. What data is to be entered in InterbankSettlementAmount field? 

This mandatory field is used to provide details about the amount of money moved between the instructing agent and instructed agent. Settlement amount + currency. Datatype is amount.

36. What is meant by ChargeBearer field? 

It is a mandatory field providing details about the party bearing the transaction charges. Data type is code. It is defined as DEBT charges borne by Debtor CRED charges borne by Creditor SHAR-charges are shared SLEV following service level. As per the current RBI policy the charges are borne by the Debtor. 

 

  

Session15- ISO20022 standard Message Implementation Knowledge Question Answer Phase1–30 to 4 Question

Session15- ISO20022 standard Message Implementation Knowledge Question Answer Phase1–30 to 33 Question

30. What is InstructedAgent? 

This mandatory field gives information about agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s). It is defined by using FinancialInstitutionIdentification- ClearingSystemMemberIdentification- MemberIdentification. It is mandatory in RTGS implementation. In case of Own Account Transfer this field provides the RBI IFSC. The value for this Field tag ‘InstructedAgent’ should be the IFSC code of the Head office of the Receiving Bank. 31. How to use the field CreditTransferTransactionInformation ? It is mandatory and is a set of elements providing information on individual transactions. Only one occurrence allowed for Customer Payment in RTGS system and 10 or more for NEFT. In case of Pacs.009 used for MNSB request multipal occurrence based on number of participants is allowed. The elements are: PaymentIdentification , PaymentTypeInformation , ChargesInformation , Debtor , DebtorAccount, , DebtorAgent , Purpose , ……., RemittanceInformation .

31. How to use the field CreditTransferTransactionInformation ? 

It is mandatory and is a set of elements providing information on individual transactions. Only one occurrence allowed for Customer Payment in RTGS system and 10 or more for NEFT. In case of Pacs.009 used for MNSB request multipal occurrence based on number of participants is allowed. The elements are: PaymentIdentification , PaymentTypeInformation , ChargesInformation , Debtor , DebtorAccount, , DebtorAgent , Purpose , ……., RemittanceInformation .

32. How to use PaymentIdentification field? 

It is a mandatory field giving set of elements used to reference a payment instruction. Type: This message item is composed of the following PaymentIdentification element(s):

i) InstructionIdentification Presence: [0..1] Definition: Unique identification, as assigned by an instructing party for an instructed party, to unambiguously identify the instruction. Usage: The instruction identification is a point to point reference that can be used between the instructing party and the instructed party to refer to the individual instruction. It can be included in several messages related to the instruction. Data Type: Max35Text Format: maxLength: 35 minLength: 1 During the transition of existing member systems to the new ISO message formats, it is used for supplementary identification, such as the legacy transaction reference number (R41/R42.2020). 

ii) EndToEndIdentification Presence: [1..1] Definition: Unique identification, as assigned by the initiating party, to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. Usage: The end-to-end identification can be used for reconciliation or to link tasks relating to the transaction. It can be included in several messages related to the transaction. Usage: In case there are technical limitations to pass on multiple references, the end-to-end identification must be passed on throughout the entire end-to-end chain. During the transition of existing member systems to the new ISO message formats, the EndToEndId should follow the 16 digits UTR pattern of the existing RTGS system, identified with the 6 character codeword prefix “/XUTR/”. The existing UTR format is:  Participant System ID (First four Characters of sending Bank’s IFSC Code)  Service Tag (One Character) Example : “H” for host  Unique-ID comprising of Date (Julian date YYDDD) & Sequence Number (6 digits numeric)

iii) TransactionIdentification This is a mandatory field. Definition: Unique identification, as assigned by the first instructing agent, to unambiguously identify the transaction that is passed on, unchanged, throughout the entire interbank chain. Usage: The transaction identification can be used for reconciliation, tracking or to link tasks relating to the transaction on the interbank level. Usage: The instructing agent has to make sure that the transaction identification is unique for a pre-agreed period. Data Type: Max35Text Format: maxLength: 35 minLength: 1 In our case it is the Unique Transaction Reference (UTR) which would be of 22 characters Format is: XXXX- Sender IFSC [4] X-Payment System [1] X-Channel [1] YYYYMMDD-Date [8] nnnnnnnn- Sequence Number [8] Codes for Payment System (X) are: R->RTGS N->NEFT A-> ACH The Channel Identifier (X) may be used to identify channels such as Internet banking, Cash Management, Treasury, ATM, etc.

Channel ID Values NG-RTGS 9 Internet Banking 1 Cash 2

Management Treasury 3 ATM 4 Other 5 

Session 14- Mapping and translation guidelines during coexistence of MT and MX/ISO20022

 Session 14- Mapping and translation guidelines during coexistence of MT and MX/ISO20022 

Basic principles for mapping & translation

Whenever mapping / translating between the various format options during the coexistence phase, the PMPG recommends to apply the mapping scheme as highlighted in the illustration below and the detailed mapping rules described in the following sub-chapters. ISO20022 provides more structured and granular data for the identification of a “party” in the name & address component than the SWIFT FIN F option. Therefore, mapping from MX/ISO20022 to MT address details will naturally lead to a loss of data structure. 

The name and address data for creditor and debtor in ISO20022 use the complex data type PartyIdentification135_2 which is comprised of the simple data type Name, the complex data types Postal Address (PostalAddress24_1) and Identification Party38Choice_2. 

The account details for debtor and creditor are expressed as the complex data type CashAccount38_2. The max number of characters including the account number that this data structure can contain is 819. The current fields 50 & 59 in the MT103 message allow a maximum of 175. In the F option, the number of usable characters without counting the delimiters is 166 (34x for the account number and 4 * 33x for name/address). 

This means the MX party fields can contain 4 times more characters than the corresponding MT fields. This will require field and content prioritization rules when mapping the party content from a source MX message into MT. These mapping rules will apply and truncation issues will occur during the co-existence period only. SWIFT will always deliver the original message to the receiver, however, to facilitate in-house processing, tools will be available to utilize the (central or onsite) translation for the provision of the SWIFT MT equivalent in addition. This will allow the receiver to consult the original ISO20022 message in case data was truncated during the conversion to the SWFIT FIN message.

Mapping table during coexistence of MT and MX/ISO20022

1. Structured MX/ISO20022 > Structured SWIFT FIN

Field mapping from structured MX/ISO20022 to structured MT

Market Practice Guideline #7: Structured customer data elements in MX/ISO20022 should be mapped to the respective sub-field of structured option F of SWIFT FIN. This will allow to preserve a certain level of structure (1/name, 2/address, 3/country/town). 

During this mapping from MX to MT, the data elements belonging to the "Address" and "Town" group will be consolidated, leading to the loss of certain granularity of data. Furthermore, not all data available in the various ISO20022 address elements may fit into the 4*35 lines of the SWIFT FIN format.

 During this mapping from MX to MT, the data elements belonging to the "Address" and "Town" group need to be consolidated, leading to the loss of certain granularity of data. Furthermore, not all data available in the various ISO20022 address elements may fit into the 4*35 lines of the SWIFT FIN format. Whenever data is truncated during this mapping due to space limitation, the indicator "+" must be added by the translation tool at the end of the respective line/data element

– Example for field mapping from structured MX/ISO20022 to structured MT

The mapping will be done based as per the following steps and prioritization of data (see previous page): 

• Step 1: Map XML fields into the appropriate subfields of the F option if no BIC present as per the column "Position in subfield". Use the comma ("," without space) as a delimiter so separate the various available data elements in the sub-fields 2/… (address) and 3/XY/… (town). 

• Step 2: If LEI is present do not use second line for name, truncate if needed using the ‘+’ character at as the last character. Truncate any other line the same way. Mapping rules for LEI element:

o Place LEI on last line of 50F or 59F, if space allows.

o For 50F, insert a 6/XY/LEIC/ before LEI. XY is the country code of the debtor. 

o For 59F, insert a 3/XY/LEIC/ before LEI. XY is the country code of the creditor. 

• Step 3: If LEI not present use two lines for the name and truncate any other line, indicating truncation with the + character 

• Step 4: If no LEI and single line name use two lines for the Country, town etc. 

• Step 5: If no second line for any other field use two lines for the street and building

Example without LEI for 50F:

Example with LEI for 50F:

The ISO country code preceding the "/LEIC/LEI identifier" is not meaningful in this particular context as it is a repetition of the country of the domicile of debtor or creditor. Nevertheless it is aligned with FATF 16 recommendation implementation and allows to maintain a standard interpretation of the field and an automated processing / validation of the payment message. For more information about the LEI ("Legal Entity Identifier), please refer to the discussion papers and industry updates that the PMPG published in this context3 . 

Source - 3 Link to PMPG document centre: https://www.swift.com/about-us/community/swift-advisory-groups/payments-market-practicegroup/document-centre/document-centre 

Field from mapping from structured MT to unstructured MX/ISO20022

The challenge to map structured customer data from structured SWIFT FIN F option to ISO20022 is that the FIN fields are not as granular as the data elements in ISO20022. As a consequence, the data in the FIN subfield "Address" (2/…) and "Town" (3/XY/…) may contain richer content than the target element in ISO20022. For instance, subfield "Address" could contain street name, street number, building name, floor number and many more. A similar challenge exists for the subfield “Town" (data after 3/XY/…) that could contain data such as postal code, district name, country sub-division etc. Therefore, the mapping from structured SWIFT FIN to structured ISO20022 comes with the risk that the data mapped to the designated elements may be polluted by the inclusion of additional data, as shown in the following diagram (not allowed):

Structured customer data in SWIFT FIN (F option) should therefore be mapped into "Name (Nm)" and unstructured "Address line (AdrLine)" elements in MX/ISO20022. In order to keep the transparency and the benefits of the original FIN structure, the mapping of the SWIFT FIN subfields should apply the same structure and include the original qualifiers 2/ for address and 3/ for country and town. Those should be copied and included at the beginning of the respective (two or three occurrences of) AdrLine in ISO.

Mapping rules if LEI can be located in field 50F or field 59F of SWIFT FIN message:

• Field 50F: Locate LEI after 6/XY/LEIC/… and map it to the LEI element in MX/20022 (the information before the LEI can be dropped)

 • Field 59F: Locate LEI after 3/XY/LEIC/… and map it to the LEI element in MX/20022 (the information before the LEI can be dropped

Map unstructured MX/ISO20022 with 2/ and 3/ qualifiers to structured SWIFT FIN

Market Practice Guideline #10: In case not all occurrences of "AdrLine" in the ISO20022 message start with 2/ or 3/, the target format should be the unstructured SWIFT FIN format (K- or no letter option). The mapping of the fields will be as follows: 

• Name: Map to element "Nm" (Name) to line 1 of MT FIN field 50 / 59 option (K- or no letter option) • Address: Map all occurrences of "AdrLine" to the residual lines of MT FIN field 50 / 59

A potential space issue will occur if the data of the ISO20022 business component Debtor or Creditor exceeds the capacity of 4*35 characters in total. Although CBPR+ is restricted to max. 3 occurrences of AdrLine, there could be Market Infrastructures allowing 4 or more occurrences. If the data mapped from unstructured ISO20022 does not fit into unstructured SWIFT FIN, this will be indicated with a truncation sign "+" at the last line of the truncated element/line. The user of the MT message must ensure procedures are in place how to deal with truncated data available in the original MX message.

 
Map unstructured SWIFT FIN to unstructured MX/ISO20022

The mapping of unstructured data from ISO20022 to SWIFT FIN is relatively straight-forward. The main challenge of mapping unstructured customer data from SWIFT FIN to ISO20022 is that the ISO20022 message has a dedicated data element for the Name, even in the unstructured format.

• Name: Map line 1 of MT FIN field 50 / 59 to element "Nm" (Name) 

• Address: Map line by line, 2, 3 and 4 of the SWIFT FIN field 50 / 59 to 

ISO20022 element "AdrLine" (line 2 to first occurrence of AdrLine, line 3 to second occurrence of AdrLine, etc.) Note: There are cases where the name exceeds one line. The above described mapping could therefore lead to the result that a part of the name information will be mapped to the element "AdrLine".

 

Session 13- Variety of unstructured and structured formats in SWIFT FIN & ISO20022

Variety of unstructured and structured formats in SWIFT FIN & ISO20022

 Compared to the unstructured SWIFT FIN format, the unstructured ISO20022 provides some degree of structure as it contains the mandatory element "name" (Nm). Even more transparency will be achieved when the fully structured option in ISO20022 will be used due to the granularity of the data definition.

Comparison of data elements in SWIFT FIN and ISO20022

The increased data unambiguousness will significantly increase data quality in payments messages; however, it comes with a substantial challenge during the coexistence of SWIFT FIN and MX/ISO20022: the different data options are not fully interoperable in both directions. While more granular/structured data can easily be mapped into aggregated/unstructured data elements (e.g. ISO20022 structured -> structured SWIFT FIN), it is much more difficult to map aggregated/unstructured data in to more granular/structured data element.  

– Overview of different standards/options and mapping challenges (red arrows)

Group - https://www.linkedin.com/groups/9322201/

Blog - https://bankingpayments.blogspot.com/

VBLOG- https://www.youtube.com/@LoveBanking

#jobsbeanbag #lovebanking #prashantpaymentspost

Session 12 - ISO20022 - PACS.008 Message FLOWS Happy / Reject / Recall

ISO20022 - PACS.008 MESSAGE FLOWS - Happy Path 

Step 1: A retail customer initiates a Credit Transfer payment by filling all the desired details (Beneficiary details, Amount of Transfer, Date, and others). The IT system of the Debtor bank converts the customer’s instruction into a Pain.001 message and injects it into the bank’s payment engine.

 Step 2: Debtor Bank’s payment engine performs different checks (like AML, Sanctions screening, Risks, and others). Further, the bank also performs balance checks on the Debtor’s account and returns a Pain.002 message to the Debtor indicating successful processing of the message.

 Step 3: Debtor Bank debits the Debtor’s account and sends a Pacs.008 message via CSM. 

Step 4: CSM validates & settles the payment. It returns a Positive Status message (Pacs.002) to the Debtor Bank indicating successful validation. 

Step 5: CSM forwards the Pacs.008 to the Creditor bank.

Step 6: Creditor Bank receives the Pacs.008 from the CSM, validates the payment (performs checks like AML, Sanctions, Risks, Balance Checks, and others) and completes the processing. Funds are credited to the beneficiary’s account and Camt.054 (Credit advice) is sent.  

ISO20022 - PACS.008 MESSAGE FLOWS - Reject Flow - 1 

Step 1: A retail customer initiates a Credit Transfer payment by filling all the desired details (Beneficiary details, Amount of Transfer, Date, and others). The IT system of the Debtor bank converts the customer’s instruction into a Pain.001 message and injects it into the bank’s payment engine. 

Step 2: Debtor Bank’s payment engine performs different checks (like AML, Sanctions screening, Risks, and others). Further, the bank also performs balance checks on the Debtor’s account and returns a Pain.002 message to the Debtor indicating unsuccessful processing of the message. The payment may be rejected due to reasons like Insufficient funds, Incorrect details or payment would have failed to clear Sanction Checks or AML check

ISO20022 - PACS.008 MESSAGE FLOWS - Reject Flow - 1 

Step 1: A retail customer initiates a Credit Transfer payment by filling all the desired details (Beneficiary details, Amount of Transfer, Date, and others). The IT system of the Debtor bank converts the customer’s instruction into a Pain.001 message and injects it into the bank’s payment engine. 

Step 2: Debtor Bank’s payment engine performs different checks (like AML, Sanctions screening, Risks, and others). Further, the bank also performs balance checks on the Debtor’s account and returns a Pain.002 message to the Debtor indicating successful processing of the message. 

Step 3: Debtor Bank debits the Debtor’s account and sends a Pacs.008 message via CSM. 

Step 4: CSM validates the Pacs.008 message received and rejects the payment due to reasons like the incorrect format of the message or so. It returns a Negative Status message (Pacs.002) to the Debtor’s Bank.

ISO20022 - PACS.008 MESSAGE FLOWS - Return Flow 

 

Step 1: A retail customer initiates a Credit Transfer payment by filling all the desired details (Beneficiary details, Amount of Transfer, Date, and others). The IT system of the Debtor bank converts the customer’s instruction into a Pain.001 message and injects it into the bank’s payment engine. 

Step 2: Debtor Bank’s payment engine performs different checks (like AML, Sanctions screening, Risks, and others). Further, the bank also performs balance checks on the Debtor’s account and returns a Pain.002 message to the Debtor indicating successful processing of the message. 

Step 3: Debtor Bank debits the Debtor’s account and sends a Pacs.008 message via CSM. 

Step 4: CSM validates & settles the payment. It returns a Positive Status message (Pacs.002) to the Debtor’s Bank indicating successful validation. 

Step 5: CSM forwards the Pacs.008 to the Creditor bank. 

Step 6: Creditor Bank receives the Pacs.008 from the CSM, validates the payment (performs checks like AML, Sanctions, Risks, Balance Checks, and others). Creditor Bank returns the payment for one or more of the reasons like Invalid Account number, Account is closed/dormant/blocked, Invalid Beneficiary’s IBAN or BIC and sends a Pacs.004 message to the Debtor bank via CSM. 

Step 7: CSM validates and returns a Positive Status message (Pacs.002) to the Creditor’s Bank indicating successful validation of Pacs.004. 

Step 8: CSM forwards the Pacs.004 to the Debtor bank. 

Step 9: Funds are credited to the Debtor’s account and Camt.054 (Credit advice) or a Pain.002 is sent to the Debtor.

 

JobGroup - https://www.linkedin.com/groups/9322201/

Banking Group- https://www.linkedin.com/groups/9809571/

Blog - https://bankingpayments.blogspot.com/

VBLOG- https://www.youtube.com/@LoveBanking

#jobsbeanbag #lovebanking #prashantpaymentspost

Session 11 - SWIFT Go by SWIFT

The launch of SWIFT Go is a milestone for the cross-border payments space. 

 

The banking industry remains under enormous pressure to improve cross-border payments. In order to address the growing competition of Fintechs and other non-bank players, they need to focus on enabling instant and frictionless transactions with full transparency and strong security. To tackle some of the remaining pain points, SWIFT launched a new service in July 2021.

Known as SWIFT Go, it is designed to enable faster, more predictable and competitively priced low-value cross-border payments for small businesses and consumers. So far, 11 global banks, collectively handling more than 41 million low-value cross-border payments per year, have already gone live with the service and 120 banks have also signed up, with many more expected to join.1 So how is the industry driving the initiative forward?

Building on gpi

SWIFT intends the new service to build upon the foundational success of SWIFT gpi, which was launched four years ago and has already significantly improved high-value cross-border payments in terms of speed, transparency and tracking capabilities, as flow reported in the September 2021 article “SWIFT gpi: a progress report”.   

Speaking at this year’s Festival of Finance, Sebastian Rojas, Head of Product, Payment Solutions, SWIFT noted, “when we introduced gpi a few years ago, the intention was to start introducing best practices at a multilateral level between banks. The focus was on transparency, the ability to monitor payments and – perhaps most importantly – the effort to bring finality of credit to international payments. Today we can see that banks are providing this visibility to end clients and, from a B2B perspective, therefore, we have dramatically improved high-value cross-border transactions.”

With those foundations laid, the banking community is able to respond to further client expectations and industry developments. One such example is that the payment industry is gradually moving towards full principal pay solutions – where the full amount sent by the payer is exactly equal to the full amount received by the beneficiary and no deductions are made along the way, which means end-to-end pricing transparency up-front. The roll-out of SWIFT Go is the banking community’s answer to this industry trend and is also a direct response to new entrants that are offering services for retail and low-value payments.

swift Go Architecture

SWIFT Go is designed to provide a seamless service offering for banks and clients alike, and can help improve low-value payments in three main ways:

1. An enhanced customer offering: This can be delivered through full predictability of payment conditions (time, fees, amount) and by the full payment value being delivered to end customers through SWIFT Go banks. In turn, this will result in improved payment processing, which can even be performed instantly where available.
2. Increased harmonisation: The single format requirement where a common currency guide is provided for SWIFT Go banks, as well as simplified fee options to help banks bilaterally agree, implement and calculate the commercial conditions for SWIFT Go, will foster standardisation.
3. Cost reduction: This common currency guide, along with stricter network validation and SWIFT Go’s Reporting Engine, which supports reconciliation and bilateral billing, will drive higher straight-through-processing (STP) rates between correspondents, reducing costs. There is also a roadmap to achieve full STP over time.

An industry-wide effort

For Marc Recker, Global Head of Product, Institutional Cash Management at Deutsche Bank, the strength of this network is critical. “The biggest asset we have as correspondent banks is the network. If we can provide access to the reach of 11,000 banks across the globe, there is no solution that can compete with the correspondent banking industry,” he said.

As a result, the first phase of SWIFT’s adoption strategy for the new service is focused on onboarding the major eligible market infrastructures and clearing banks, providing a strong foundation for growth (see Figure 2 for an outline of the full strategy).

Source - https://flow.db.com/cash-management/swift-go-low-value-payments-rethought

 

Session10 = Some of ISO20022 and Payment industry Terminology

 Session10 = Some of ISO20022 and Payment industry Terminology 

ACH: Automated Clearing House that is used to clear retail payments between banks in a country or region. 

ASN.1: Abstract Syntax Notation One. Data specification and encoding technology jointly standardised by ISO, IEC (International Electrotechnical Commission) and ITU (International Telecommunication Union), and widely used across several industries, such as cellular telephony, signaling, network management, Directory, Public Key Infrastructure, videoconferencing, aeronautics and Intelligent Transportation. One of the two official ISO 20022 syntaxes with XML. 

Business justification: Document prepared by an organisation wishing to develop and register ISO 20022 content. The document describes the content to be developed, the purpose and benefits for the industry. It is submitted for the approval of the ISO 20022 Registration Management Group (RMG).

Coexistence: The situation of multiple standards existing at the same time in the same business space. Within SWIFT, this refers to the coexistence between the MT and MX standards. This also refers to the set of measures being taken to make the situation easier to handle by the community (publication of mapping rules, translation services and so on).

Components: See Business components and message components.

Corporate action: An event initiated by a public company that affects the securities issued by the company. Also refers to the sub-domain of the financial services industry related to the management of such events.

 CSD: Central Securities Depository. An organisation holding securities to enable book-entry transfer of securities. The physical securities may be immobilised by the depository, or securities may be dematerialised (so that they exist only as electronic records).

Dictionary: Part of the ISO 20022 Repository that contains all items that can be reused during business modelling and message definition activities. 

EAI: Enterprise Application Integration. Middleware to connect applications and communication interfaces. Typical EAI software includes features for mapping data between various formats, enriching messages with data from other systems and orchestrating message flows.

FIN: The messaging service offered by SWIFT for the secure and reliable exchange of MT messages in store-and-forward mode. By extension, the syntax used to format these MTs. FIX: Financial Information 

eXchange. A communication protocol designed by the FIX Protocol Limited (FPL) for transmission of messages in specific areas of the securities processing life cycle, for example the pre-trade and trade spaces. 

FpML: Financial products Mark-up Language. A primarily XML-based communication protocol dedicated to OTC derivative contracts processing life cycle. FpML is owned by the International Swaps and Derivatives Association (ISDA).

Giovannini Protocol: In its 2003 report, the Giovannini Group, as advisor to the European Commission, published a report identifying 15 barriers to efficient EU cross-border clearing and settlement. The Giovannini Group, under the chairmanship of Dr Alberto Giovannini, CEO of UNIFORTUNE SGR SpA, stated that SWIFT, through the Securities Market Practice Group (SMPG), should define a solution to eliminate Barrier 1, which cites national differences in information technology and interfaces used by clearing and settlement providers. 

InterAct: A private SWIFT network established between members of a financial community for the purpose of exchanging transaction and other financial data.

 Interoperability: Capability to easily exchange business information while using different message standards. ISO 20022 promotes global use of syntax-neutral business and message components as a common denominator to achieve interoperability between standards using different syntaxes. 

ISO: The International Organization for Standardization. An international standard-setting body, composed of representatives from more than 160 national standards organisations, that promulgates worldwide standards in a variety of domains aiming at facilitating cross-border exchanges of goods, services and techniques. 

ISO 15022: An ISO standard that describes the syntax to be used for developing securities messages used mainly to support back-office related transaction flows. It replaced the previous securities messaging standard ISO 7775. 

ISO 20022 RA: Registration Authority that offers the services described in an ISO standard on behalf of and under a contractual agreement with the International Organization for Standardization.

ISO 20022 Repository: Repository maintained by the ISO 20022 RA, which contains the financial business models, message definitions and components defined in compliance with the ISO 20022 standard. 

ISO 20022 RMG: Registration Management Group in charge of the supervision of the ISO 20022 registration process. 

ISO 20022 SEG: Standards Evaluation Groups in charge of validating candidate ISO 20022 messages within the scope of the business justification and ensuring that they address the needs of their (future) international community of users. Message: A set of structured information exchanged between two parties involved in a financial transaction. 

Message component and element: A reusable data structure used for assembling message definitions. The data defined in a message component is ‘traced’ back to the business components and business elements. In simple terms, business components define the business meaning; message components create data structures for messaging. 

MI: Market Infrastructure. A system that provides services to the financial industry for trading, clearing and settlement, matching of financial transactions and depository functions. 

Middleware: Software that enables data to be exchanged among different systems with standard communication components and tools for formatting, mapping and processing.

MT: The traditional ‘: tag: value’ Message Types for use on the FIN service offered by SWIFT. 

MX: An XML message exchanged over SWIFTNet, whether or not ISO 20022 compliant. 

MyStandards: A web-based platform provided by SWIFT to manage and implement standards and related market practices.

 RTGS: Real Time Gross Settlement System

Semantics: The study of meaning, usually in language. The word is often used in ordinary language to denote a problem of understanding that comes down to word selection or connotation. 

SEPA: Single Euro Payment Area. Standards Editors: Standards work station developed by SWIFT to support the development of ISO 20022 compliant models and messages and the ISO 20022 RA services.

Standards Editor: ‘Lite’ version of the Standards Editors, developed by SWIFT and offered to submitting organisations. 

SWIFT: Society for Worldwide Interbank Financial Telecommunication. See www.swift.com. Syntax: Physical format of a message used to identify and represent the conveyed pieces of information. 

T2S: TARGET2 Securities. An initiative of the Eurosystem. It is an IT platform that aims to make settlements across national borders simpler and more cost-efficient. TARGET2: The Eurosystem-owned European Real Time Gross Settlement (RTGS) system.

TARGET2 is one of the largest high-value payment systems in the world. Taxonomy: The classification in a hierarchical system, typically organised by supertype-subtype relationships, also called generalisationspecialisation relationships, or less formally, parent-child relationships. 

TC 68: ISO Technical Committee 68 in charge of all ISO standards to support financial services. Translation rules: Set of rules to be used to map the pieces of information included in a message expressed in one syntax to the equivalent message expressed in another syntax. 

UML: Unified Modeling Language. The visual modelling language used in ISO 20022 to represent the industry business model. 

XBRL: eXtensible Business Reporting Language. An open data standard for financial reporting. 

XML: eXtensible Mark-up Language. Popular syntax to encode documents (or messages) electronically on the Internet. XML allows communities to define their own identifiers (or tags) and format (or data type) for each component of a message. One of the two official ISO 20022 syntaxes with ASN.1.

https://bankingpayments.blogspot.com/ 

Session 8 = Knowledge Question Answer for ISO20022 -Phase1 21 to 30

Session 8 = Knowledge Question Answer for ISO20022 -Phase1 21 to 30 

21. What is CreationDateTime and how it is different from the CreationDate defined in BAH? 

CreationDateTime is the mandatory filed containing date and time at which this message was created and the CreationDate is the date and time at which the message header is created. The format of the date time is same throughout the message. . 

22. How the field NumberOfTransactions is defined? 

It provides the number of individual transactions contained in the message. The default value is 1 for Pacs.008 and Pacs.009 messages and ten(10) or more for NEFT. In some situations, viz. at the end of the batch or end of day, the number of NEFT transactions can be less than 10. In MNSB request this is defined as the number of participants in the batch. The datatype is numeric. It is a mandatory field. 

23. What the field TotalInterbankSettlementAmount used for?

This mandatory field gives the total amount of money moved between the instructing bank and the instructed bank. Data Type: ActiveCurrencyAndAmount This data type must be used with the following XML Attribute: Currency (Ccy) which is typed by ActiveCurrencyCode. Format: Amount MinInclusive 0 TotalDigits 18 fractionDigits 2 Maximum digits = 18. Decimal mark excluded from count. Note: The decimal separator is a dot. ActiveCurrencyCode ActiveCurrency

The currency code must be a valid active currency code of three (3) contiguous letters. For Indian Rupee the active currency code is INR Example: 2345 

24. What is InterbankSettlementDate ?

It is a mandatory field providing the settlement date. Data Type: ISODate 

25. How SettlementInformation is defined?

 This is a mandatory element defined as: Definition: Specifies the details on how the settlement of the transaction(s) between the instructing bank and the instructed bank is completed. 

26. How to define SettlementMethod ? 

It is the method used to settle the (batch of) payment instructions with Data Type: Code It is a mandatory field. One of the following SettlementMethod1Code values must be used:

Code Name Definition

CLRG ClearingSystem Settlement is done through a payment clearing system. 

COVE CoverMethod Settlement is done through a cover payment.

INDA InstructedAgent Settlement is done by the agent instructed to execute a payment instruction. 

INGA InstructingAgent Settlement is done by the agent instructing and forwarding the payment to the next party in the payment chain.

27. How to interpret InstructingAgent? 

It is the agent that instructs the next party in the chain to carry out the (set of) instruction(s). It is mandatory in RTGS implementation 

28. What is FinancialInstitutionIdentification field used for? 

This is a mandatory field which provides the identification of the Financial Institute referred to. 

29. What details to be entered in ClearingSystemMemberIdentification field?

This mandatory field is used to enter the details of the participating bank. The mandatory sub-field MemberIdentification is used to provide IFSC of the concern participant. In case of InstructingAgent this field contains the IFSC of sending bank, while for the InstructedAgent this field contain the IFSC of the receiving bank. 

30. What is InstructedAgent? 

This mandatory field gives information about agent that is instructed by the previous party in the chain to carry out the (set of) instruction(s). It is defined by using FinancialInstitutionIdentification- ClearingSystemMemberIdentification- MemberIdentification. It is mandatory in RTGS implementation. In case of Own Account Transfer this field provides the RBI IFSC.