Claims:1. A method of real time testing of payment transactions between financial institutions independent of a payment platform, the method comprising:
in an automated payment platform simulator (100) configured to mimic the payment platform:
receiving one or more messages from one or more of the financial institutions in a pre-defined standard format, the messages pertaining to business messaging functionality based on pre-defined business scenarios (202);
establishing one or more instances of the payment platform simulator (100) for the payment transactions (204);
sending, to the one or more of the financial institutions, one or more messages, in the pre-defined standard format, in response to the received one or more messages (206);
parsing the one or more messages from one of configured input folder, output folder or configured message queue (MQ) (208);
validating the one or more messages for technical and business correctness based on one or more testing scenarios (210); and
outputting results of validation either in real time or in a result queue (212).

2. The method of claim 1, wherein the pre-defined standard format is either the messaging format required by the payment platform or a messaging format that is convertible to the messaging format required by the payment platform.

3. The method of claim 2, wherein receiving the one or more messages further comprises converting the one or more messages, by the payment platform simulator (100), to the messaging format required by the payment platform.

4. The method of claim 2, wherein sending, to the one or more of the financial institutions, one or more messages further comprises converting the one or more messages, by the payment platform simulator (100), to a messaging format required by the one or more of the financial institutions.

5. The method of claim 1, wherein the one or more financial institutions are payee or payer.
6. The method of claim 1, wherein the technical validation comprises schema validation based on the pre-defined standard format specific to the payment platform and the business validation comprises one or more of locale based validations and regulatory validations.

7. The method of claim 1, wherein the testing scenarios are either pre-defined or user-defined.

8. The method of claim 1, wherein validating the one or more messages comprises performing sanity checks on the one or more messages and generating error correction messages for errors detected as part of the results of validation.

9. The method of claim 8 further comprising regression testing of corrected one or more messages.

10. A payment platform simulator (100) system comprising:
one or more data storage devices (102) operatively coupled to one or more hardware processors (104) and configured to store instructions configured for execution by the one or more hardware processors to:
receive one or more messages from one or more of the financial institutions in a pre-defined standard format, the messages pertaining to business messaging functionality based on pre-defined business scenarios;
establish one or more instances of the payment platform simulator (100) for the payment transactions;
send, to the one or more of the financial institutions, one or more messages, in the pre-defined standard format, in response to the received one or more messages;
parse the one or more messages from one of configured input folder, output folder or configured message queue (MQ);
validate the one or more messages for technical and business correctness based on one or more testing scenarios; and
output results of validation either in real time or in a result queue.
11. The payment platform simulator system of claim 10, wherein the pre-defined standard format is either the messaging format required by the payment platform or a messaging format that is convertible to the messaging format required by the payment platform.
12. The payment platform simulator system of claim 10, wherein the one or more hardware processors are further configured to convert the one or more messages to the messaging format required by the payment platform.

13. The payment platform simulator system of claim 10, wherein the one or more hardware processors are further configured to convert the one or more messages to a messaging format required by the one or more of the financial institutions.

14. The payment platform simulator system of claim 10, wherein the one or more financial institutions are payee or payer.

15. The payment platform simulator system of claim 10, wherein the technical validation comprises schema validation based on the pre-defined standard format specific to the payment platform and the business validation comprises one or more of locale based validations and regulatory validations.

16. The payment platform simulator system of claim 10, wherein the testing scenarios are either pre-defined or user-defined.

17. The payment platform simulator system of claim 10, wherein the one or more hardware processors are further configured to validate the one or more messages by performing sanity checks on the one or more messages and generating error correction messages for errors detected as part of the results of validation.

18. The payment platform simulator system of claim 10, wherein the one or more hardware processors are further configured to perform regression testing of corrected one or more messages.
, Description:FORM 2

THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003

COMPLETE SPECIFICATION
(See Section 10 and Rule 13)

Title of invention:
PAYMENT PLATFORM SIMULATOR

Applicant:
Tata Consultancy Services Limited
A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India

The following specification particularly describes the embodiments and the manner in which it is to be performed.

TECHNICAL FIELD
[001] The embodiments herein generally relate to real time testing of payment transactions between financial institutions, and more particularly to a payment platform simulator for facilitating the testing independent of a payment platform.

BACKGROUND
[002] Countries across the world are today migrating to real time integrated or centralized payment platforms to facilitate real time clearing and settlement of financial transactions. This requires financial institutions to upgrade or renovate their existing payment infrastructure in order to be able to connect to the new integrated payment platform and carry out real time clearing and settlement of transactions. This necessitates that by the time the new integrated payment platform is designed and functional, the financial institutions also have to complete making changes to their payment infrastructure. Additionally, financial institutions also have to complete testing the changes prior to industry testing phase of the new integrated payment platform. Financial institutions need to devise an effective assurance strategy as their internal testing also needs to ensure compatibility of payment applications with the new integrated payment platform.

SUMMARY
[003] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems.
[004] In an aspect, there is provided a method for real time testing of payment transactions between financial institutions independent of a payment platform, the method comprising: in an automated payment platform simulator configured to mimic the payment platform: receiving one or more messages from one or more of the financial institutions in a pre-defined standard format, the messages pertaining to business messaging functionality based on pre-defined business scenarios; establishing one or more instances of the payment platform simulator for the payment transactions; sending, to the one or more of the financial institutions, one or more messages, in the pre-defined standard format, in response to the received one or more messages; parsing the one or more messages from one of configured input folder, output folder or configured message queue (MQ); validating the one or more messages for technical and business correctness based on one or more testing scenarios; and outputting results of validation either in real time or in a result queue.
[005] In another aspect, there is provided a payment platform simulator system comprising: one or more data storage devices operatively coupled to the one or more processors and configured to store instructions configured for execution by the one or more processors to: receive one or more messages from one or more of the financial institutions in a pre-defined standard format, the messages pertaining to business messaging functionality based on pre-defined business scenarios; establish one or more instances of the payment platform simulator for the payment transactions; send, to the one or more of the financial institutions, one or more messages, in the pre-defined standard format, in response to the received one or more messages; parse the one or more messages from one of configured input folder, output folder or configured message queue (MQ); validate the one or more messages for technical and business correctness based on one or more testing scenarios; and output results of validation either in real time or in a result queue.
[006] In yet another aspect, there is provided a computer program product comprising a non-transitory computer readable medium having a computer readable program embodied therein, wherein the computer readable program, when executed on a computing device, causes the computing device to: receive one or more messages from one or more of the financial institutions in a pre-defined standard format, the messages pertaining to business messaging functionality based on pre-defined business scenarios; establish one or more instances of the payment platform simulator for the payment transactions; send, to the one or more of the financial institutions, one or more messages, in the pre-defined standard format, in response to the received one or more messages; parse the one or more messages from one of configured input folder, output folder or configured message queue (MQ); validate the one or more messages for technical and business correctness based on one or more testing scenarios; and output results of validation either in real time or in a result queue.
[007] In an embodiment of the present disclosure, the pre-defined standard format is either the messaging format required by the payment platform or a messaging format that is convertible to the messaging format required by the payment platform.
[008] In an embodiment of the present disclosure, the one or more hardware processors are further configured to convert the one or more messages to the messaging format required by the payment platform.
[009] In accordance with the present disclosure, the one or more hardware processors are further configured to convert the one or more messages to a messaging format required by the one or more of the financial institutions.
[010] In accordance with the present disclosure, the one or more financial institutions are payee or payer.
[011] In accordance with the present disclosure, the technical validation comprises schema validation based on the pre-defined standard format specific to the payment platform and the business validation comprises one or more of locale based validations and regulatory validations.
[012] In accordance with the present disclosure, the testing scenarios are either pre-defined or user-defined.
[013] In accordance with the present disclosure, the one or more hardware processors are further configured to validate the one or more messages by performing sanity checks on the one or more messages and generating error correction messages for errors detected as part of the results of validation.
[014] In accordance with the present disclosure, the one or more hardware processors are further configured to perform regression testing of corrected one or more messages.
[015] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the embodiments of the present disclosure, as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS
[016] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[017] FIG.1 illustrates an exemplary block diagram of a payment platform simulator for real time testing of payment transactions between financial institutions, in accordance with an embodiment of the present disclosure;
[018] FIG.2 illustrates an exemplary flow diagram of a method for real time testing of payment transactions between financial institutions by the payment platform simulator of FIG.1, in accordance with an embodiment of the present disclosure;
[019] FIG.3 illustrates a high level integration of the payment platform simulator of FIG.1 in a payment transaction scenario, in accordance with an embodiment of the present disclosure;
[020] FIG.4 illustrates an architectural representation of various exemplary functional units of the payment platform simulator of FIG.1, in accordance with an embodiment of the present disclosure; and
[021] FIG.5 illustrates a 3-tier architectural representation of the payment platform simulator of FIG.1, in accordance with an embodiment of the present disclosure.
[022] It should be appreciated by those skilled in the art that any block diagram herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and so executed by a computing device or processor, whether or not such computing device or processor is explicitly shown.

DETAILED DESCRIPTION
[023] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[024] The words "comprising," "having," "containing," and "including," and other forms thereof, are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items.
[025] It must also be noted that as used herein and in the appended claims, the singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Although any systems and methods similar or equivalent to those described herein can be used in the practice or testing of embodiments of the present disclosure, the preferred, systems (various embodiments of the payment platform simulator tool) and methods are now described.
[026] Some embodiments of this disclosure, illustrating all its features, will now be discussed in detail. The disclosed embodiments are merely exemplary of the disclosure, which may be embodied in various forms.
[027] Before setting forth the detailed explanation, it is noted that all of the discussion below, regardless of the particular implementation being described, is exemplary in nature, rather than limiting.
[028] In view of countries adopting new integrated / centralized payment platforms for real time financial transactions, financial institutions need a tool for carrying out internal testing that can simulate business behavior of the new integrated payments platform and ensure their internal payment applications are ready for industry testing. For instance, Australia is in the process of designing and implementing the New Payments Platform, a new infrastructure or a centralized payment platform that can facilitate real time transactions between financial institutions such as National Electronics Funds Transfer (NEFT) and Real Time Gross Settlement (RTGS). Likewise, Canada and the United States are also in the process of implementing such a platform. Ordinarily a Financial Institution A would have to connect to a Financial Institution B (buddy testing) to test whether real time transactions were getting performed seamlessly and in a desired manner. However, this testing cannot happen until the centralized payment platform is ready. Again, assuming the centralized payment platform were ready, if bugs are detected during buddy testing, financial institutions may not have sufficient time to fix the bugs and perform regression testing in the limited time period that the centralized payment platform is available for industry testing. Sometimes, in order to fix bugs, major modifications may be required in the legacy systems of the financial institutions and / or business functionalities to adopt to the new centralized payment platform which may involve considerable cost, time and resources. The present disclosure provides a tool or a simulator that mimics the centralized payment platform and can help financial institutions complete their internal testing prior to availability of the actual centralized payments platform, thereby providing the financial institutions with ample time to thoroughly test their payments applications (legacy systems) for the modifications made, thus ensuring that their payment infrastructure is compatible with the new centralized payments platform. Additionally, the tool of the present disclosure can generate standard format messages specific to the integrated payments platform, such as ISO 20022 messages by receiving transaction details from the financial institutions current payment applications and rendering them in the prescribed ISO 20022 format for the new integrated payments platform. Conversion of IS0 20022 messages received from the new payments platform into a message format that can be comprehended by the financial institutions’ legacy payment systems is also achieved by the tool of the present disclosure. Thus the tool of the present disclosure facilitates internal testing as well as User Acceptance Testing (UAT) prior to industry testing.
[029] In the context of the present disclosure, the integrated payment platform or the centralized payment platform may be referred to as “payment platform” hereinafter. Likewise, the payment platform simulator of the present disclosure may also be referred to as an “automated testing platform” or “testing platform” in the context of the present disclosure. For ease of explanation the messaging format required by the payment platform may be referred particularly as ISO 20022 format.
[030] Referring now to the drawings, and more particularly to FIGS. 1 through 5, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary tool and method thereof.
[031] FIG.1 illustrates an exemplary block diagram of a payment platform simulator / testing platform 100 for real time testing of payment transactions between financial institutions, in accordance with an embodiment of the present disclosure. In an embodiment, the payment platform simulator 100 includes one or more processors 104, communication interface device(s) or input/output (I/O) interface(s) 106, and one or more data storage devices or memory 102 operatively coupled to the one or more processors 104. The one or more processors 104 that are hardware processors can be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, graphics controllers, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor(s) is configured to fetch and execute computer-readable instructions stored in the memory. In an embodiment, the payment platform simulator 100 can be implemented in a variety of computing systems, such as laptop computers, notebooks, hand-held devices, workstations, mainframe computers, servers, a network cloud and the like.
[032] The I/O interface device(s) 106 can include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like and can facilitate multiple communications within a wide variety of networks N/W and protocol types, including wired networks, for example, LAN, cable, etc., and wireless networks, such as WLAN, cellular, or satellite. In an embodiment, the I/O interface device(s) can include one or more ports for connecting a number of devices to one another or to another server.
[033] The memory 102 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, one or more modules (not shown) of the payment platform simulator 100 can be stored in the memory 102.
[034] FIG.2 illustrates an exemplary flow diagram of a method 200 for real time testing of payment transactions between financial institutions by the payment platform simulator 100 of FIG.1, in accordance with an embodiment of the present disclosure. In an embodiment, the payment platform simulator 100 comprises one or more data storage devices or memory 102 operatively coupled to the one or more processors 104 and is configured to store instructions configured for execution of steps of the method 200 by the one or more processors 104.
[035] In an embodiment, at step 202, the one or more processors 104 of the payment platform simulator 100 configured to mimic the payment platform receives one or more messages from one or more of the financial institutions in a pre-defined standard format, wherein the messages are related to business messaging functionality based on pre-defined business scenarios. For instance, there may be a transaction involving transfer of funds from Bank A (payee) to Bank B (payer). Concurrently, there may be another transaction involving transfer of funds from Bank C (payee) to Bank A (payer). The payment platform simulator 100 which mimics the payment platform can concurrently receive message from Bank A regarding a payment transfer to Bank B and also receive message from Bank C regarding a payment transfer to Bank A. In an embodiment, the pre-defined standard format is either the messaging format, such as ISO 20022, required by the payment platform or a messaging format that is convertible to the messaging format required by the payment platform. If the message is received in a format different from the format required by the payment platform, the payment platform simulator 100 may convert the received messaging format to the messaging format like ISO 20022, required by the payment platform.
[036] In an embodiment, at step 204, the one or more processors 104 of the payment platform simulator 100 are configured to establish one or more instances of the testing platform for the payment transactions. In an embodiment, the payment platform simulator 100 is a web application, wherein several messages from say, Bank A, Bank B and so on may be sent to or received from the payment platform simulator 100 concurrently. Testing of the messages to / from each of the banks for one or more messages may be performed in multiple instances of the payment platform simulator 100. A dedicated instance for each tenant makes data logging simpler and facilitates testing continuity in the event that there is an error in in any particular instance or communication.
[037] In an embodiment, at step 206, the one or more processors 104 of the payment platform simulator 100 are configured to send, to the one or more of the financial institutions, one or more messages, in the pre-defined standard format, in response to the received one or more messages. For instance, based on received message in step 202, if there is a transaction involving transfer of funds from Bank A to Bank B, the payment platform simulator 100 may send to Bank A, an acknowledgement of receipt of the message pertaining to transfer of funds to Bank B. Concurrently, the payment platform simulator 100 may also send to Bank B, a message pertaining to transfer of funds from Bank A. In an embodiment, the payment platform simulator 100 may convert the message that is in a messaging format like ISO 20022 to a messaging format that can be read by legacy systems used by the one or more financial institutions.
[038] In an embodiment, the messages sent by the payment platform simulator 100 may be customized responses configured by a user or may be pre-defined in a response repository for each business scenario, explained in detail subsequently with reference to an exemplary flow of a financial transaction.
[039] In an embodiment, at step 208, the one or more processors 104 of the payment platform simulator 100 are configured to parse the one or more messages from one of configured input folder, output folder or configured message queue (MQ). For instance, messages received by the payment platform simulator 100 may be received in the input folder or the MQ for further processing. Likewise, messages sent by the payment platform simulator 100 may be sent to the output folder or the MQ for further processing.
[040] In an embodiment, at step 210, the one or more processors 104 of the payment platform simulator 100 are configured to validate the messages received or sent by the payment platform simulator 100 for technical and business correctness based on one or more testing scenarios which may be either pre-defined or user-defined explained in detail subsequently with reference to an exemplary flow of a financial transaction. For instance, validation may involve compliance check of the message for correctness and completeness. In an embodiment, the technical validation comprises schema validation based on the pre-defined standard format such as ISO 20022 specific to the payment platform that is being mimicked. In an embodiment, the business validation may comprise one or more of locale based validations that are specific to a particular country’s platform and regulatory validations such as mandatory validations imposed by the central banking institution of a particular country. Some exemplary compliance check may pertain to, for instance, Bank A migrating from a 7 digit account number to a 10 digit account number to integrate with the centralized payment platform, currency field may not be zero, and the like.
[041] In an embodiment, schema validation performed by the payment platform simulator 100 of the present disclosure may be described with reference to an input message received as given below-
An input message as an XML message may be received via the input folder or the MQ. The input message is parsed line by and line and syntax of the message is validated to confirm if the input message confirms to XML standards. Once the parsing is complete, the message is converted into a string and sent to a schema validator. The schema validator separates the Header portion of the message (Header block) and the body portion of the message (Body block). The Header portion is validated first. The string message is extracted for information by parsing the XML message, wherein each element of the XML message is validated against the XML Schema Definition (XSD) of IS0 20022. Once the header portion is validated, the Body block is validated as explained for the Header block. Errors, if any, encountered during the validation process, may be output in the form of an error message based on the criticality of the error such as “Warning”, “Error” or “Fatal”. If there are no errors, a validated message is sent for message execution to a message engine. The message engine upon receiving the message, may execute the message depending on the scenario mentioned in the message.
[042] In an embodiment, at step 212, the one or more processors 104 of the payment platform simulator 100 are configured to output results of validation in step 210. In an embodiment, error correction messages may be generated for errors detected as part of the result of validation. The results may either be output in real time as the one or more messages are validated or they may be compiled into a result queue which may be perused later by an administrator for attending to correction of errors, if any. In an embodiment, a dashboard may be provided for displaying the result of validation.
[043] In an embodiment, the one or more processors 104 of the payment platform simulator 100 are configured to perform regression testing of corrected one or more messages to ensure correctness and completeness of messages being communicated between the financial institutions.
[044] FIG.3 illustrates a high level integration of the payment platform simulator 100 of FIG.1 in a payment transaction scenario, in accordance with an embodiment of the present disclosure. As illustrated, the payment platform simulator 100 may be sandwiched between legacy systems of the financial institutions 300 at one end and the integrated / centralized payments platform 400 at the other end to ensure that messages communicated by the legacy systems of the financial institutions 300 are correct and complete before communicating with the integrated / centralized payments platform 400. Both internal testing and UAT may be facilitated for seamless communication, and technically and business wise compliant communication between the legacy systems of the financial institutions 300 and the integrated / centralized payments platform 400.
[045] FIG.4 illustrates an architectural representation of various exemplary functional units of the payment platform simulator 100 of FIG.1, wherein the payment platform simulator 100 may have a 3-tier architectural representation as illustrated in FIG.5, in accordance with an embodiment of the present disclosure. In the illustrated architectural representation, users of the payment platform simulator 100 may send input message in ISO 20022 format. The payment platform simulator 100 validates the input message and sends out a status intimation or confirmation or required reports based on the received message back to the user. The users may configure global functions for different business and test scenarios in a Global configuration component of the payment platform simulator 100. The payment platform simulator 100 sends or receives messages either through the configured Message Queues (MQ) or the configured input/output folder. An Adhoc Message Processor of the payment platform simulator 100 allows the users to paste a sample input Extensible Markup Language (XML) which is validated against ISO 20022 XML schema and on execution posts a message to the input folder as configured to test the sanity of the payment platform simulator 100 and to test network availability. Typically, a user identified as Owner / Site Administrator (Site Admin) for the payment platform simulator 100 is provided with access rights to all the functionalities of the payment platform simulator 100. New projects and project administrators may be created only by the Site Admin. A project administrator (Project Admin) owns the project to which he is mapped as administrator by the Site Admin. The Project Admin may create users, add them to the project and assign privileges to them. A simulator manager of the payment platform simulator 100 may be used by the Site Admin / Project admin to manage users, projects and the overall configurations of the payment platform simulator 100. The basic idea of the Global Configuration is for the users to create global mappings which define attributes in messages which can be reused from the input data that was originally sent to simulator by users for generating the required response messages.
[046] A global configuration component of the payment platform simulator 100 is configured with functional units for custom data set up, custom mapping and custom messages. The customized mapping feature may be used for creating new global mappings for business / testing scenarios and modifying existing mappings. The customizing messages feature enables the users to configure different inbound messages from the payment platform simulator 100. A user interface (UI) may be provided for facilitating the customizing messages feature. The customizing data setup feature may be used to define global values for attributes. For instance, users may want a message to be archived for a certain period of time for say log validation or data mining. Such requirements may be set up by customizing suitably. The outbound messages generated using the global data setup mappings uses the attribute values set in the data setup mappings instead of values from inbound message. For instance, a beneficiary name may need a prefix like Mr. or Ms. The beneficiary name may be pulled from the input message and based on the attribute values set in the data setup mappings, the appropriate prefix may be appended to the beneficiary name pulled from the input message and an outbound message may be generated.
[047] Use case / scenario design component of the payment platform simulator 100 enables the users to create use cases for different business scenarios and to define test cases for each of the created use cases. The payment platform simulator 100 enables the user to select already configured global functions while defining the test cases.
[048] A message engine component of the payment platform simulator 100 generates output messages (status intimation, confirmation messages, reports, query responses, allegement notifications) in the pre-defined format such as ISO 20022 for all validated input messages based on the configured scenarios and mapped global functions set in payment platform simulator 100.
[049] A Reports component of the payment platform simulator 100 provides reports for all executed scenarios, corresponding messages and error transaction lists. The reports may be provided with filter options and the users may be able to export the reports generated to formats like Excel or Pdf. Dashboard option may also be provided for the generated reports.
[050] All executed / reported data may be stored in a database of the payment platform simulator 100 for generating the dashboard and reports on demand.
[051] In an embodiment, process flow involved when a user accesses the payment platform simulator 100 of the present disclosure is explained herein below.
Login: When the user logs in, the login module of the payment platform simulator 100 validates the user credentials with its database and allows the user to login based on his user privileges.
Project configuration: The user may set up details with respect to his project in a project configuration screen.
MQ Server configuration: The user may then configure the messaging server and queue via which the input message may flow in the MQ server screen.
Test Data Management: The user may then perform a onetime setup of all data configuration he/she needs for testing in the customize data set up, customized mapping and customize message screens.
Test Scenario Setup: The user may then set up user scenarios and test cases based on his/her testing needs in a scenario setup screen of the tool. He/she may also do bulk upload of scenarios or clone an existing scenario and modify details as required.
Adhoc Utility: Once all the configurations are setup, the user may open an Adhoc utility screen, browse for a sample message or paste a sample message and validate it. The ISO 20022 reader of the payment platform simulator 100 parses the message and the schema validator validates the message for technical and business correctness. Once validated, the user may click on execute to check if it is processed properly by a message generator and an output message posted to the output queue which he/she has configured. The Adhoc utility screen not only helps in easy validation and execution but also helps to perform a sanity check to see if configurations set are working correctly and as desired.
Message Execution: After configuration and sanity testing are completed, the users may post messages to the input messaging queue to which the simulator is configured to listen. The payment platform simulator 100 picks the message and parses it with the ISO 20022 reader. The payment platform simulator 100 then validates the parsed message with the schema validator and persists the message to its database. The payment platform simulator 100 then checks which scenario corresponding to the input message is configured to execute. The payment platform simulator 100 uses the scenario steps and message generator to generate the required ISO 20022 output messages, persists the output messages in the database and also posts the output messages to the configured output queue.
Reports: After message execution, users may view the report and the executed messages in a reports module. The payment platform simulator 100 provides a summary and detailed reports for at least all the designed scenarios, all the executed scenarios and inbound and outbound messages for each executed scenario. The reports may have filter options and can be exported in formats such as MS Excel. The messages may be exported into XML format.
Error Clean Up: Error details of message transactions that fail due to data or network error may be viewed by users. The error scenarios may be re-executed. Unwanted errors that are not required to be displayed may be cleaned up by the Project / Site Admin.
Dashboards: The payment platform simulator 100 may also port a dashboard corresponding to various graphical views of the report summary such as pie charts, bar graphs and so on. Based on the filter selection, the dashboard may showcase dynamic graphs. In an embodiment, the dashboard may consist of the following six panels: Report Viewer, Error Clean Up, Tester Based Execution, Scenario Execution Data, Scenario Data and User Statistics.
Archiving: The site admin may archive scenario details, global configurations and reports which are created say 30 days back (configurable parameter). Also, data that are say 60 days old (configurable parameter) may be deleted permanently.
Logging: The payment platform simulator 100 performs a lot of logging to help users understand activity flow and message flow of the messages that are executed. Activity Log displays details of activities of the logged user. Message Log displays flow details of every message received/posted for all executed scenarios. The users may also download the logs such as technical, server, activity and message logs for future reference or technical investigations.
[052] An exemplary flow of a financial transaction may be explained as given below.
Say there are four messages involved in an exemplary locale Australia:
• Pacs008 - Customer credit transfer from Financial Institute (Payer) to Financial Institute (Payee)
• Pacs002 - Payment status report from Payer to Payee
• Pacs009 - Credit transfer from Payer to Payee
• Camt54 - Debit Credit Notification from Financial Institute (FI) to Customer
Step1: A Payer (FI) initiates funds transfer through his/her account. The FI upon receiving the funds transfer request checks if the account balance is adequate for the funds transfer to be processed. Once the balance check is completed, the Payer initiates an ISO 20022 message called pacs008 after Bank State Branch (BSB) number lookup, wherein the BSB uniquely identifies each bank branch participating in the transaction like the Indian Financial System Code (IFSC) number in India. Pacs008 is then sent by the Payer to the payment platform simulator 100 for routing the message to the desired Payee (FI).
Step 2: The Payee upon receiving Pacs008, verifies the status of the Payee account (beneficiary). If the account is in active status, the Payee applies the funds to the Payee customer account. Once the funds are credited into the Payee account, the Payer bank generates Pacs002 message. The Payee then sends the Pacs002 message to the payment platform simulator 100.
Step 3: The payment platform simulator 100 forwards the Pacs002 message to the appropriate Payer. The Payer upon receiving the Pacs002, verifies if there is a corresponding Pacs008 which was sent by it earlier. An End to End ID and transaction ID are used for this verification. An associated timestamp is also verified to ensure that the Pacs002 was received within a Service Level Agreement (SLA) defined by the payment platform simulator 100. If Pacs002 was received outside the SLA, then a time out message is sent to the Payee and the funds transferred are reversed. Typically, this is an unlikely event. End customers are notified about the successful transfer. Payer receives notification that the amount has been successfully credited to the beneficiary. Payee is notified about the successful credit of funds to his/her account.
Step 4: Payer bank then generates Pacs009 and sends it to the payment platform simulator 100 for forwarding the Pacs009 message to the central banking institution of the locale (such as Reserve Bank of India). The central banking institution upon receiving the Pacs009 debits the account of the Payer and credits the account of the Payee bank. Subsequently, the central banking institution sends Camt54 to the payment platform simulator 100 which is then routed to both the Payer and Payee.
[053] With reference to the exemplary flow of a financial transaction explained herein above, exemplary pre-defined and user defined business scenarios that may be facilitated by the payment platform simulator 100 of the present disclosure are as given below:
Pre-defined business scenarios:
1) An account number present in the Pacs008 input message is activated for real-time faster payment
2) Before construction of the Pac002 message, the Payer checks if corresponding Pacs008 is available.
User defined business scenarios:
1) Check for Payer initiating duplicate transactions
2) Check for Bank State Branch (BSB) number look up failure
3) Check for beneficiary account refusing acceptance of credit
[054] With reference to the exemplary flow of a financial transaction explained herein above, exemplary business and test scenarios that may be facilitated by the payment platform simulator 100 of the present disclosure are as given below.
Business scenario - Beneficiary account refuses acceptance of credit, the payment platform simulator 100.
The payment platform simulator 100 is configured to listen to input messages that may be received via MQ and/or the input file folder. Say, Pacs008 message is available in the MQ. The message reader component of the payment platform simulator 100 picks up the Pacs008 message from the MQ. The schema validator validates the XML message against the XSD of ISO20022. Additionally, predefined business validations are also performed at this step. Once the message is found to be correct and complete, it is sent to one of the instances of the message engine for processing. The message engine upon receiving the Pacs008 message, will apply the predefined / user-defined scenarios on the message and send it to the centralized payments platform. The payment platform simulator 100 of the present disclosure mimics the centralized payment platform. So, the message engine, calls upon the Message builder component of the payment platform simulator 100 and provides instruction to build Pacs002 message which is a response to the Pacs008 message. In real time, the Pacs002 message is sent by Payee to the Payer through the payment platform simulator 100 in the absence of the centralized payment platform.
In a scenario wherein the beneficiary account refuses acceptance of credit, an exemplary test scenario may be as explained herein below.
Test Scenario - Message engine calls the test scenario for “Beneficiary account refuses acceptance of credit”. An error code for “Beneficiary account refuses acceptance of credit” is pulled up from a list of Error codes along with the description. The Pacs002 message is built with an error message and the error code and is sent as a response to message Pacs008. The response to Pacs008 is sent to the output MQ which in turn sends it to the FI’s payment application.
[055] Based on the above description of the present disclosure, it may be understood that payment platform simulator 100 is independent of any physical infrastructure. It provides a dynamic ongoing certification tool for financial institutions. It has the flexibility to allow many forms of input so as to support centralized payment platforms specific to any geography or locale. The payment platform simulator 100 allows for manual testing as well as automated testing. Testing scenarios may be pre-defined or user defined as and when new regulations are introduced in a particular geography. The payment platform simulator 100 also has the capability to convert messages from ISO standard to native language of the locale under consideration. Considering the huge volume of transactions that are possible from each back and concurrently from multiple banks, it is impossible for a human mind to parse and process such information. Also, schema validation and the dynamics involved add to the complexity of data handling that necessitates an efficient and agile tool to ensure that payment messages being communicated between financial institutions are correct and complete.
[056] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments of the present disclosure. The scope of the subject matter embodiments defined here may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language.
[057] The scope of the subject matter embodiments defined here may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope if they have similar elements that do not differ from the literal language of the claims or if they include equivalent elements with insubstantial differences from the literal language.
[058] It is, however to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software means. Alternatively, the embodiments of the present disclosure may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[059] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules comprising the payment platform simulator 100 of the present disclosure and described herein may be implemented in other modules or combinations of other modules. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The various modules described herein may be implemented as software and/or hardware modules and may be stored in any type of non-transitory computer readable medium or other storage device. Some non-limiting examples of non-transitory computer-readable media include CDs, DVDs, BLU-RAY, flash memory, and hard disk drives.
[060] Further, although process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously.
[061] The preceding description has been presented with reference to various embodiments. Persons having ordinary skill in the art and technology to which this application pertains will appreciate that alterations and changes in the described structures and methods of operation can be practiced without meaningfully departing from the principle, spirit and scope.