ScienceSoft’s Practices to Maximize Financial Software Longevity

Can Modern Software Repeat the 40-Year Longevity of Legacy Financial Tools?

Back in the day, BFSI software design was focused primarily on reliability. Many solutions succeeded in that regard: 43% of US banks still retain 40-year-old systems built on COBOL. However, faultless performance is not the only reason why incumbents stick to their heritage systems. The rigid monolithic nature and the sheer volumes of stored data make revamping legacy software extremely risky and costly.

Newer financial techs powered by cloud, API, AI/ML, and blockchain haven’t yet had a chance to showcase their durability to the same extent. While it’s comparatively flexible, scalable, and interoperable, modern software heavily depends on constantly evolving third-party services and frameworks. Hence, it tends to accumulate technical debt way faster than the old-school tools. Quick aging, ongoing fragmented changes, and uncertain regulations for emerging techs are the top concerns related to the longevity and TCO of new BFSI solutions.

5 Pitfalls Hampering Financial Software Longevity — and How We Navigate Them

8 Issues Caused by Poor Financial Software Longevity

How We Foster Longevity Throughout Financial Software Lifecycle

Here are ScienceSoft’s main activities to extend the useful life of BFSI solutions while optimizing capital investments and maintenance costs.

Step 1. Financial software inception

At this stage, we discover the client’s long-term goals and gather requirements for the financial solution. Here’s what it usually includes:

• Interviewing project stakeholders to get a complete vision of the current operational needs, short-term goals, and long-term plans for the financial solution (e.g., adding functionality to support new digital service models later on).
• Conducting interviews with specialists who will use the software (e.g., actuaries, underwriters, customer service agents) to elicit their challenges and expectations.
• (for financial software products) Researching the market and target audience needs and defining the in-demand features to include in the solution.
• (for existing software and systems in development) Analyzing the available software documentation.
• Auditing our client’s financial IT infrastructure to understand its capabilities and limitations.
• Determining global, region- and domain-specific regulatory compliance requirements.
• Analyzing the regulatory frameworks of adjacent industry sectors and regions to leave room for potential software adaptation to new laws, e.g., concerning emerging techs like AI and blockchain.
• Creating a list of functional and non-functional requirements for the financial solution.
• Validating requirements with the client’s stakeholders to ensure their accuracy, clarity, and completeness.

Step 2. Financial software design

At ScienceSoft, this stage involves a range of technical decisions that define the financial solution’s ability to scale and accommodate changes according to the changing business needs. This covers:

• Designing an optimal feature set for the financial solution, including security and compliance features. We prioritize functionalities based on their importance to software sustainability and user adoption.

ScienceSoft's best practice: For fintech products, focusing on end-user value is crucial as it secures steady demand. By fostering a product-first mindset among development teams and flexibly addressing shifts in user preferences, we ensure our fintech clients get the right products capable of bringing long-term revenue. We prioritize Agile development methodologies to smoothly accommodate potential changes at late project stages without breaking the budget.

• Designing the business logic, i.e., mapping the rules and constraints that will guide the system’s behavior. This step covers designing specialized logic components for finance automation, e.g., custom actuarial formulas, AI models for credit decisioning, blockchain smart contracts for parametric payouts, etc.
• Defining the business logic components that can be reused across multiple features. Reusable logic contributes to software operational consistency and enables faster software evolution with minimized risks to the integrity of its underlying business rules.
• Designing integrations (APIs, custom connectors, etc.) between financial software components and between the software and other systems.

ScienceSoft's best practice: Adopting the API-first approach, which implies designing APIs before other solution components, ensures easy financial software integration with third-party systems. The strategy is especially beneficial for fintech SaaS products targeting corporate customers and enterprise BFSI apps intended for multi-entity use.

• Designing a scalable, flexible, and resilient architecture that will enable the smooth functioning and evolution of financial software. We rely on modular SOA, microservices, and serverless architectures that allow for separation of concerns (SoC) and component (logic, UI, database) decoupling. SoC makes it easier to reuse components across the financial app and allows for independent component development and maintenance, meaning that future upgrades and fixes can be rolled out quickly and without downtimes for the live app.

• Composing a reliable tech stack that will support accurate operations, security, and upgradeability of financial software. ScienceSoft employs low-code/no-code platforms where relevant to introduce agile financial solutions that can be easily customized by the client’s non-IT teams. Being technology-agnostic, we compare the offers of multiple technology providers to pick the techs that ensure the best cost-to-performance ratio.

ScienceSoft's best practice: If our client’s priority is to minimize dependency on third-party tech vendors, we go the opposite way and create fully custom financial solutions with proprietary low-code frameworks and plugins for convenient software evolution.

• Designing human-centered UX and UI for role-specific financial apps. By prioritizing usability over trendy appearance, we ensure the aesthetics will not pose any risks to convenient user journeys and user adoption. Plus, in the long term, changing the app’s visual style according to the bank’s evolving brand book is less expensive than in-depth UX adjustments.

Step 3. Financial software development

• This is the stage where we transform the approved design into financial software code, run the necessary testing, integration, and configuration procedures, and set the ready solution live. It includes:

• Implementing DevOps (CI/CD, container orchestration, etc.). It helps eliminate manual errors throughout delivery, ensuring code integrity and minimizing regression risks.
• Coding the financial solution’s back end and creating user interfaces using secure coding standards like OWASP ASVS. ScienceSoft’s financial software engineers apply standardized code design patterns like Singleton, Observer, Adapter, or Factory Method to improve the structure of the code, making it easier to understand and maintain.
• Applying component-specific practices to drive longevity, for example:
  • Soft-coding financial values in actuarial, underwriting, accounting formulas and financial document templates.
  • Building asynchronous REST APIs to prevent API response delays when processing long-running requests like retrieving detailed account transaction histories or generating large financial reports.
  • (for AI-powered financial software) Setting up a scalable data processing framework and a high-capacity environment for continuous AI model retraining.
  • (for blockchain-based financial software) Developing proxy contracts to enable on-demand changes in financial smart contracts.
• Testing the financial solution in parallel with development (may involve functional testing, usability testing, code vulnerability assessment, and more).
• Establishing financial software integrations with the necessary systems and running integration tests to ensure smooth and secure data flows between the connected solutions.
• Setting up and configuring a scalable and secure financial software infrastructure (cloud-based, on-premises, or hybrid). We advocate for using cloud as a means of horizontally auto-scaling software capacities, which is critical for financial solutions with fluctuating demand, such as payment gateways or trading platforms.
• Implementing financial software security mechanisms that have shown to be future-proof, like role-based access control, multi-factor user authentication, data encryption, and malicious activity detection. We make sure to leave the possibility to update mechanisms that are fast-evolving (e.g., encryption protocols, authentication methods, threat detection techniques) to stay protected against emerging cyber threats.
• Implementing financial data backup and recovery mechanisms to prevent data losses and operational downtimes in case of failures or breaches.
• Delivering all necessary technical documentation (documented source code with README files and comments, test reports, API documentation, a configuration guide, a maintenance guide, manuals for end users, etc.) to facilitate financial software maintenance and evolution.

Step 4. Financial software maintenance and evolution

Here are the activities we commonly conduct during managed maintenance to ensure the relevance of financial software in the long run:

• Continuous logging and monitoring of the financial software performance (tracking KPIs like throughput, latency, load, and spare capacity) and accuracy (e.g., via automated transaction logic checks and data cross-validation).
• Financial software performance optimization, e.g., via load balancing among processing servers to improve availability or by optimizing financial database queries to minimize latency.
• L1–L4 support to quickly handle emerging software and infrastructure issues and user inquiries.
• Regular security and compliance assessments with reports on the revealed issues and recommendations on fixing vulnerabilities and bridging compliance gaps.
• Monitoring user experiences with the financial app and collecting user feedback to run continuous app improvements in accordance with user expectations.
• Continuous regression testing during financial software evolution to ensure that new and changed code pieces do not hamper solution performance and accuracy.
• Regular codebase refactoring to handle potential post-release code smells (duplications, design inconsistencies, etc.) that may degrade financial app performance over time.
• (for AI-powered financial software) Continuously fine-tuning AI model hyperparameters to improve model accuracy and meet evolving legal demands for AI explainability.

Step 5. Financial software modernization

ScienceSoft’s financial software revamp activities proved to help our BFSI clients extend the useful life of their digital solutions by 5–10 years on average.

• Financial software migration to the cloud (rehosting, replatforming).
• Financial solution rearchitecting (e.g., strangling the monolith architecture to microservices, decomposing UI into microfrontends) to make it more scalable, flexible, and integration-friendly.
• Recoding financial apps built on legacy languages and platforms (e.g., PowerBuilder, COBOL, Delphi, VB) or aging languages (outdated .NET and Java versions) using modern programming techs.
• Delivering new features to introduce consistent financial service automation and improve user experience (e.g., extend self-service options for insurance clients). We reuse the logic, UI, and database components of the existing financial solution whenever possible to avoid unnecessary development efforts.
• Developing a strategy to address gaps in security and compliance measures and assisting with its implementation.
• Remediating financial app accessibility issues (e.g., insufficient color contrasts, improperly labeled forms, no alternative text and transcripts for media files) to make the app convenient for users with disabilities.

ScienceSoft's best practice: We introduce changes to legacy financial software incrementally, taking time to conduct regression tests and make sure the adoption rate is sufficient. Our team usually runs deployments on holidays and weekends to prevent financial service downtimes.