Finastra Global PAYplus - Time to upgrade your Payments Platform to the next-generation Fusion Platform
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.