My Greeting to Functional people! My name is Piyush Srivastava, and I’m working as in functional/Automation for more than 5 years on various projects with respect to Banking and payment domain as a Senior Consultant and SME. Now I’m working in *Luxoft * where I got great chance to upskill myself in better way. I wanted to share some Banking concepts for the Functional people.
With the help of this article, I wanted to encourage you to start using this basic concept in your daily work or at least give it a try it will increase your Banking and payment domain concepts for sure once you start using and looking deep dive with this basic as I will keep adding my knowledge with this type of post which I gathered with my experience in this domain.
Payments
Payment is the mechanism of sending or giving money in a currency either in cash, cheque or electronically for a goods or services or fees or donation etc. Electronic payments are done through the banking channels from account of client A to account of client B of the same bank or different bank in the same country or foreign country in the same currency or different currency!
Payments done by the corporates using their corporate internet banking channels are basically classified for corporate payments. Payments done by the retails/individuals using their internet.
banking channels are basically classified for retail payments.
This method is also known as EFT - Electronic Fund Transfer.
*Different Payment File format: *
Here we would only talk about these payment initiation file formats and their structures (we will
talk about different PAIN messages and SWIFT messages separately):
● ISOXMLV3
● ISOXMLV2
● IDOC
● PAYMUL
● NACHA
Current generation of payment file formats preferred is ISOXMLV3 which consist of a major volume of payment initiation. The advantage of ISOXMLV3 format as it is of ISO20022 standards which is recognized worldwide.
ISOXMLV3 Credit:
Though ISO has designed V8, most of payments need is covered in V3 hence it is widely used and still organizations do not feel to move to the latest version of ISO XML format.
The CustomerCreditTransferInitiation message is sent by the initiating party which is client to the debtor agent which is Bank. It is used to request transfer funds from the debtor to the creditor account. This format is also known as PAIN001.
This message format can contain one debtor and many creditors or multiple debtors and multiple creditors.
The CustomerCreditTransferInitiation message also allows for a Mixed mode where the Payment Information block can be repeated and each Payment Information block can contain one or several Credit Transfer Transaction Information blocks.
ISOXMLV2:
The structure of ISOXMLV2 credit file is almost the same as ISOXMLV3 but being the trailing version, it doesn't have lots of new tags which are present in ISOXMLV3 and some of irrelevant.
tags are removed from ISOXMLV3. Sample would be provided in the reference section, in case more details needed. A ISOXMLV2 Debit file has the same structure but the only Creditor details are replaced in the Debtor section and vice versa. This file is used to initiate debit transactions from Client’s customers who would be debtors in this case and Initiating party will be creditors.
IDOC Format:
One PEXR2002 message can contain multiple Extended Payment Order (PAYEXT) and DirectDebit (DIRDEB) messages. Therefore, where a customer has multiple payment instructions to be actioned, a single PEXR2002 message may be sent. The use of the SAP IDoc PEXR2002 format is intended to enable customers to use a single format to send all their payment order and direct debit instructions to the Bank in a standardized way.
IDoc or Intermediate Document is a standard SAP document format. IDocs allow different application systems to be linked via a message-based interface. There are three main aims behind
the use of IDocs:
● The structured exchange of business documents so that they can be processed
automatically.
● The various degrees of structural complexity as displayed by different application systems can be reduced to a structure which is as simple as possible.
● IDocs allow for extensive exception handling before the data is posted to the application.
IDocs are defined and considered on two levels, the technical and the business level. The former allows them to support application-independent functions, e.g. routing and handling technical
exceptions.
Technical level
Defined by the three record types compatible with the IDoc interface:
● Control record: The Control Record contains the administration information for technical processing, as well as the IDoc and message type. This information specifies the structure and the content of the next part. Each IDoc type can support several message types.
● Data record: The Data Record holds the actual application data, which is stored in segments. A segment comprises segment fields as the smallest unit of the IDoc.
● Status record: The Status Record keeps the processing status (“What has happened to the IDoc before now?).
EDIFACT:
EDIFACT (Electronic Data Interchange for Administration, Commerce, and Transport) is the computer-to-computer exchange of business data in standard formats. In EDIFACT, information is organized according to a specified format set by both receiving and sending parties, allowing an automated computerized transaction that requires no human intervention or re-keying at either end. Early developments of EDI were driven primarily by large buying organizations - supermarkets, chain stores, health services - which had the financial muscle to influence their trading partners to adopt a standard method of electronic trading, initially largely to the benefit of the buyer, though ultimately with benefits for both sides. The information contained in an EDIFACT message set is the same as on a paper document, and it can support the movement of large amounts of data within the body of the message. When using automatic data interchange, a much more rigid discipline needs to be exercised regarding data presentation and exchange rules than in the care of paper documents.
The EDIFACT syntax has evolved out of United Nations Guidelines for Trade Data Interchange (known as TRADECOMS) and American National Standards Institute X12 committee rules for data interchange (ANSI X12). These standards were agreed by the ISO committee as an international standard (ISO 9735). EDIFACT is widely accepted as the international EDI standard adopted by
organizations that have a global presence EDIFACT can be seen as an international, cross-sector language used for exchanging electronic messages. Like any other language, it Uses a dictionary-DIRECTORY.
EDI
Actually EDIFACT is just a standard for electronic data interchange. We should first understand what EDI is. EDI (Electronic Data Interchange) is the direct communication of trading messages between computer systems, using national and international telecommunications networks. Many libraries and suppliers may currently use EDI simply for transmitting Orders and
receiving Acknowledgements. However, EDI messages may also be used to transmit other information, like Invoices etc.
The main advantage of EDI is its ability to prevent unnecessary human intervention and manual activity in reviewing, formatting, reading and transmitting information shared by different businesses by agreeing standards and protocols for data sharing. Moreover, EDI facilitates Straight through Processing (STP) by virtue of its ability to reduce manual activity in the process.
EDIFACT has hierarchical structure, where the top level is referred to as interchange, and the lower level contains multiple messages which consist of segments which in turn consist of
composites. The final iteration is elements which are derived from the United Nations Trade Data Element Directory (UNTDED) and are normalized through the EDIFACT standard.
Top comments (0)