1 / 20

‘ How To’ and ‘ How Not Too’ Test Payment Systems

‘ How To’ and ‘ How Not Too’ Test Payment Systems. Divya Murthy Anoop Nair Infosys Limited (NASDAQ: INFY). Abstract.

lalo
Télécharger la présentation

‘ How To’ and ‘ How Not Too’ Test Payment Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ‘ How To’ and ‘ How Not Too’ Test Payment Systems Divya Murthy Anoop Nair Infosys Limited (NASDAQ: INFY)

  2. Abstract • Payment systems are perhaps the most important, yet volatile components in a financial institution's framework. An efficient payment system is crucial to the functioning of the financial markets and the entities involved. • In the past few years there have been several changes in the services offered in the payments landscape due to external circumstances. These changes are usually time bound and thus arises the need to develop quality systems within these stringent timelines. There is immense pressure on the IT departments within banks to provide payment systems which meet the recent regulatory requirements and also incorporate the latest technology trends within the existing legacy systems. • Also, the changes in the payments industry in the form of new entrants, regulations, and technologies have resulted in financial institutions adopting new strategies and increasing their technology spend on these applications. The options available for the banks to embrace these new technologies have their own set of challenges to address. • Legacy systems- Though generally stable and a comfortable option for the banks to continue with, they have the drawback of being dated and not being able to integrate with systems built on latest technology. • Vendor applications - Albeit this is an “easy-to-procure-and-use” option for banks, the ability of these applications to cater to the client specific needs of the banks is minimal. • Correspondingly, testing a plethora of such systems can assume paramount importance as these systems grapple not just with changes within the organization but also with regulatory and technological changes.This paper highlights some of the best practices that are prevalent in the industry while pointing out a few generic fallacies pertaining to testing payment systems to ensure the applications are stable, reliable and resilient • Keywords: Testing of payment systems, best practices, fallacies

  3. Payments Landscape • Payment systems constitute the backbone of the banking and financial industry • Post the financial crisis, the need for an efficient payment system was recognized • New Banking Regulations, Payment Channels, New Products – pose a challenge • Testing involves multiple flows, systems, file formats Fig 1. Payment Life Cycle

  4. Payment Trends and Associated Challenges

  5. Why this Paper? • An attempt to highlight some of the desirable and quite a few of the undesirable practices/ methods that testers adopt while testing payment systems • Create awareness on mitigating poor practices in payment systems testing, thereby reducing the risks that banks are prone to in the event of any casualty that can be attributed to undesirable testing practices.

  6. Scenario 1: Dealing with Data complexity Bank A in the Belgium receives an MT202 SWIFT message from Bank X also in the Belgium to be passed on to Bank Y in London to fulfill an MT103 payment instruction. • How will the QA testers validating payments with several possible data combinations ensure through test coverage with optimal utilization of time and effort?

  7. Scenario 1: Dealing with Data complexity ( Contd.. ) • Banks use resident banking software applications or an OTS vendor software applications/ products, customized to suit its needs. • Testers maintain a homogeneous focus on elements like data, value and field. • Functional testing of payment systems involves the field by field validation of all the data coming in from the source/ upstream system, transformations and then finally, transmission to the downstream system. • DDT is a functional testing technique which emphasizes greatly on the reuse of data.

  8. Scenario 2: Prioritization of effort in a time bound scenario • There is a major change in a regulatory requirement involving cross currency payments. This would require a significant amount of rework in all the stages of the lifecycle which would result in considerable delay. However, the delivery schedule does not get changed as the regulatory body has made it mandatory for all FIs to adhere to the new norm within a specified period of time.

  9. Scenario 2: Prioritization of effort in a time bound scenario (Contd..) • Delays in previous stages/ frequent regulatory changes affect testing. • Testers are somehow expected to accommodate such exigencies and adapt quickly. • Onus is on the testers to come up with the ideal test bed which: • Prioritizes the scripts • Ensures coverage of all the high priority functional test conditions • Prioritizes the E2E scenarios too

  10. Scenario 2: Prioritization of effort in a time bound scenario (Contd..) • RBT prioritization criteria • Likelihood of failure • Impact of failure • Risk Matrix • Quantify risks versus impact • Ensures coverage of all high priority scenarios • Higher the priority, earlier its coverage in the test cycle • High severity defects detected early • Contributes to optimal resourcing • Adds to client value

  11. Scenario 3: Integrating multiple systems and channels • A customer, who holds a Current account in Bank A in US, initiates a money transfer to fund his account in India with Bank B to fulfill an EMI obligation. His account in the US is debited with $ 1000 and the bank promises to credit his account in India in 2-3 working days. • However, even after a week the payment has not reached Bank B. Bank A is unable to figure where the payment is held up while the customer is being penalized by Bank B for delaying his EMI payment. Sounds familiar Bank’s Back Office Systems Trading Corporate Retail Treasury Lending Trade Finance Card Systems Authentication Manager Back Office Integration Server Gateways Integration Layer & Channel Manager Internet POS Kiosk Mobile ATM Smartphone

  12. Scenario 3: Integrating multiple systems and channels ( Contd..) • Multitude of channels involved in the payments domain • E2E Testing provides an insight into the functioning of each payment application system and validate services, messages, interfaces and business processes. • Payment flow involves myriad systems giving rise to various challenges while doing E2E testing: • Multiple points of convergence of payments channels • Applications developed and tested by different vendors in different regions/environments • Availability of multiple test environments and E2E test environments • E2E schedule tracking & monitoring

  13. Scenario 3: Integrating multiple systems and channels ( Contd..) E2E Test Methodology

  14. Scenario 4 : Effective system performance • A bank has tens of thousands of payments coming in one particular day, as opposed to the few thousands which are usually the norm. The sudden spurt of traffic has resulted in a server crash. How can a bank foresee such situations and react efficiently when such exigencies arise?

  15. Scenario 4 : Effective system performance ( Contd..) • Performance Tests – Ensure systems can take the anticipated volumes within a reasonable time frame • Stress Tests – Identify the break point to help define the switch over/ recovery plan • Need to Performance/ Stress Test driven by • Regulatory Requirements • Transaction Volumes • Migration • New Products • Fraud • Disaster Recovery

  16. Scenario 5 : Securing Payments • Mr. John notices an advertisement from Bank XY while browsing the net which promises some interesting benefits on his account. He follows the link which requires him to login with his ID and password. He browses through the content and gets back to doing what he was doing. The next day, he sees a debit of $ 5000 from his Current account not initiated by him. Who could have initiated this payment?

  17. Scenario 5 : Securing Payments ( Contd..) • Increasein fraudulent activities due to introduction of new technologies and new payment avenues • Tools used by existing QA teams to be analyzed and then the security testing processes, tools to be fit into the current process • Types of testing to be done on Payment systems • Network Security • Database Security • Web Application Security

  18. Conclusion • Payment systems expected to absorb and align themselves to the advances in technology, regulatory changes and latest developments in business process reengineering • Processes which are mutually beneficial to FIs and their customers • Innovations in payments landscape • Testing these improved systems would prove cumbersome unless radical improvements and advancements are made in testing practices, tools and processes • Prudence to be exercised in identifying the shortcomings of the existing practices/ systems

  19. References • Infosys project experience • Infosys resources (www.infosys.com)

  20. Q&A: divya_murthy@infosys.com anoop_nair05@infosys.com 20

More Related