Cards and Payments

Driven by technology modernization and industry transformation, Finastra is upgrading its flagship Global PAYplus (GPP) Classic platform to the next-generation GPP Fusion platform. Fusion offers Flexibility of fine-grained services, open APIs as well as the adoption of the FusionFabric cloud ecosystem where banks can partner with Fintechs to build new apps. GPP Fusion natively supports ISO20022 messaging which is increasingly being used in domestic and cross border payments. Fusion is also offering better performance, UI, and workflow rules than the Classic platform. Finastra over time is also sunsetting its product support for GPP classic platform indirectly pushing its customers to migrate to the new Fusion Platform. Hence, for many banks and payments organizations presently using Finastra's GPP Classic suite of Products, upgrading to the Fusion platform is becoming a necessity.

GPP Classic to Fusion migration is a complex endeavor. There is no lift and shift strategy possible as GPP Classic and Fusion have inherent design differences. Static data especially rules and rule conditions need thorough review during migration to ensure no required functionality is missed out. Detailed cutover and co-existence planning are also required to ensure a seamless migration. From our Payments industry experience and partnership with Finastra, we discuss here a few learnings and best practices that should be followed during such GPP Classic to Fusion migration programs.

•       A dedicated Requirements and Design workshop involving all stakeholders (like Finastra, Business, Operations, Finance, BA, Tech, testing, etc.) is a very effective way in expediting Requirements Management process (including timely signoffs).

•       Capture Non-functional requirements early so that proper design-build-test cycle is followed.

•       Plan for Global BRD/CRD - Try to find out commonalities between various scheme requirements - the platform should be designed to meet worst-case conditions - e.g. special character/NLS handling - if even one of the schemes needs Special/NLS character handling the platform should be designed to handle it.

•       Review existing bank documentation (FRD/IRSD/Test Cases from Classic platform) and Industry Documentation for completeness of the requirements - always validate from a business if some of the legacy requirements should not be migrated.

•       Trust working code over documentation - For Legacy platform analysis always, trust actual platform behavior through Proof of Concept Testing rather than documentation - remember many times documentation is not updated during ad-hoc changes for production fix etc.

Interface Development:

•       Building an Enterprise-wide Integration Layer which leverage Fusion native APIs will be helpful for standard integration pattern with partner systems.

•       Banks should minimize Finastra Product side customization as much as possible. Any such product gaps should be handled outside GPP through in-house development of the Integration Layer. This reduces cost and Product dependency.

•       Integration layers should be reused across markets as much as possible, but separate codebase can be maintained for any regional differences.

•       For Industry uploads ideally they should be natively supported by GPP Fusion and not through any Bank specific interface layers. This way banks can save any future interface development cost in case industry file specification is changed in the future.

•       Interface Requirements Specification Documents(IRSD) should detail out all Exception and Error code handling (Industry-GPP Internal Error Codes-Channel specific error code etc.).

Static Data (Profiles and Rules) management:

•       Due to differences in Architecture and Database Schema GPP Classic Static Data cannot be directly migrated to Fusion.

•       Some of the big Global Banks have thousands of Rule and Rule Conditions - unfortunately, many of those Rules/conditions are never used and hence should be dropped during migration. Discovery tools in assessing the use of Rules is a good way to assess which Rules should be migrated.

•       Fusion Platform should be ideally redesigned through developing a Business Requirements Document(BRD) and Configuration Requirements Document(CRD).

Infra and Environment:

•       Many organizations are using common infrastructure for multiple GPP offices and using Cloud solutions for cost optimization- detailed planning and co-existence testing (both functional & non-functional) are becoming key to the success of this strategy.

•       Plan early - most banks have a lot of procedural lead time (architect approvals, security team alignment, Purchase Order for Server Hardware, etc.)

•       Platform consolidation helps in reducing:

•       High TCO due to customization and rolling out

•       Reduced cost and operations impact for Server Patching

•       Less dependency on vendors as a limited number of technologies to be supported

•       Storage cost by centralizing payments data in cloud which can be reused

Test Strategy:

•       Exhaustive Automation and Regression Testing are key to optimize the Cost of Quality and Speed of Delivery

•       Product Testing - a good coverage in product testing ensures fewer issues late in the program. This should include comparison testing with Classic as well. Build an automated regression pack as after each new product release/defect fix a full Product Testing should be performed.

•       Point to Point(P2P) Testing - This helps in finding any gaps between GPP, Partner, and Integration Layers.

•       System Integration Testing(SIT) - Functionality testing performed on the payment message to understand the system behavior is correct.

•       User Acceptance Testing(UAT) - Test payment messages are simulated to understand if the desired business results are derived. These tests are mostly to scrutinize the various business rules that are set up owing to different business requirements.

•       End to End Testing(E2E)- Payment flows are tested from front end partners via the interface to the payment engine GPP fusion. The key is to have all Partners connected to the relevant environment that is plugged with GPP fusion.

•       Co-existence Testing - If multiple schemes/GPP Offices are using the same Infra co-existence testing is required to ensure setup change in one office does not impact other GPP office/scheme behavior.

•       Production Acceptance testing(PAT): 2 days' worth of Production payments are dropped into the OAT test environment (reserved for PAT) to check the STP rate and understand the nuances of error messages. Issues log is created for all the genuine NSTP payments and resolution sought before going live in production. This gives the familiar feel and confidence for the staff to work in the new system on the D day.

•       Industry Testing: Payments Messages are exchanged with other banks in the scheme to validate the behavior is as expected.

•       Non-Functional Testing (NFT): This covers performance, throughput, security, and other non-functional parameters.

•       Production Verification Testing (PVT): Before going live - Sunday PVT should be performed on select production payments to ensure if the results are as expected. They are forced out of the Filtered message queue or from forward processing. Sunday PVT is always followed by controlled start to open the links in a controlled manner after certain amounts of key payment messages are tested to be working as expected.

Migration Planning - cutover & co-existence planning:

•       Plan cutover with co-existence of both the Classic and Fusion Platform.

•       Detailed cutover planning is required with Tasks, Owners, Sequencing and Dependency planning, Backout Plan, etc.

•       Reconciliations: A separate workstream should be formed to handle the reconciliation process in GPP Fusion vis-à-vis Classic during the Co-existence period.

•       Overall Program Plan should consider future migration planning - e.g. a Bank can decide to split the overall change in multiple personas       :

•       Phase-1 - Only Channel Side Integration Layers are changed for one market

•       Phase-2 - Divert partial traffic to Fusion from Classic - may consider a parallel run of both platforms and compare platform behavior

•       Phase-3 - Full cutover to Fusion including rules as per Industry requirements

•       Phase 4- Full decommissioning of classic platform

•       Bank can also plan 'Receive flows' first and then go live with 'Send flows'.

Operational readiness:

Operational readiness is key to the success of any Payments Platform migration program - User Training, Deep involvement of Operations in developing the Target Operating Model is critical.

•       Setup Target Operating Model(TOM) for Payments Processing and Support Teams:

-      Target workflows covering the high-level architecture of the payments processing

-      Standard Operating Procedures

-      Agreed workaround's (if any)

-      Target Governance documents

•       Training: Both Product and Process Training is required with support from Finastra. Operations team members should get access to the test/pre-prod environment to learn hands-on.

•       Business Setup Team - Change Management should be driven by the Business Setup Team

•       Entitlements and Access creations - Payments processing and Change management

-      New entitlements should be created with fresh queue names

-      SAM (system access matrix) should be designed as per the Processing area - Payments, Investigations, etc.

-      New system access for new partner/integration platforms

-      Access to GPP archive

•       Incident Management: With the light of the new systems, IT and Operations need to understand the target incident/crisis management process.

•       Reporting - New reporting and access to the right reports need to be established.

  Data migration:

•       One-time upload of Industry Data Uploads (SWIFTRef, Scheme Membership Data), Static Data, etc. need to be planned before Day 1 migration.

•       Banks should plan Data Migration close to Production Rollout.

•       Relevant Industry Data Uploads and Static Data (e.g. Customer, Accounts, Contacts Data) from other internal systems should be uploaded.

•       Due to differences between Classic and Fusion Platform, few such interfaces may need to be redesigned.

•       Static Data like Rules & Rule conditions should be manually setup based on CRD.

•       Tools/Accelerators can be used wherever possible to minimize manual intervention - e.g. scripts can be built to migrate rules/rule-conditions from the lower environment to Production environment.

•       For a period of co-existence both MT and MX Data need to be handled.

Overall Program Management:

A dedicated Program Management Office(PMO) setup and constant collaboration across business, tech, and partners will be key.

•       Build a Playbook - Develop cost & schedule models based on a pilot country rollout. Also, ensure all learnings and best practices are followed in future implementations

•       Maximize Reuse - Ensure most of the design, Integration Pattern, Product configurations, IT code changes, etc. are reused as much as possible

•       Dependency Management is Key - Ensure very tight dependency management between all stakeholder teams like Product, Partners, Infra, Tech, Operations, etc. Any slippage along the critical path will impact Program cost & schedule

•       Environment configuration/version management is very important - Only tested code for various partner systems should migrate to Production

•       Plan Program delivery in an iterative fashion - e.g. plan Finastra delivery in multiple MVPs (MVP1 for Basic setups, Global Requirements, MVP2 for regional requirements, etc.), Interface Development based on partner readiness, etc.

•       Plan your contract with Finastra/SI Vendors based on your delivery priority and capacity.

•       Expect Known unknowns and unknown unknowns!  

Final thoughts: 

GPP Classic to Fusion upgrade program needs top executive team support and alignment, a dedicated skilled team, and a world-class execution following a detailed migration roadmap. Collaboration is key to success and hence banks should partner with SI partners who have skills talents and credentials in successfully delivering similar programs.