Banking Software Development: Core Systems, Compliance and Cost

Banks and other financial institutions deal with specific challenges not faced by many other industries. Continuous operation, ability to handle a high level of regulatory scrutiny, and modernization without affecting the core services, which must run seamlessly both for customers and regulators, are the requirements every bank technology leader must consider. This guide addresses banking technology executives and neobank founders that evaluate how to create or modernize banking software with the compliance considerations in mind.

What is Banking Software Development About?

Banking software is not a single application. Instead, it includes three layers with distinct architectural requirements, functionalities, and development life cycles.

Core banking systems track and process transactions, perform accounting, compute interest rates, perform deposits and loan servicing. This layer represents the heart of banking operations and the base for the other parts, and it tends to change very slowly.

Digital banking channels interact with customers and represent the front-end part of banking systems. Mobile banking applications, web portals, and increasingly chatbots are the examples of digital channels in modern banking.

Middleware and integration connect the core system and the digital channels with translation between different data formats, business logic, and connection to external providers through third-party APIs.

A company providing banking software development services usually works on all layers of banking systems architecture, but the approaches to development of each of them differ dramatically.

Core Banking Systems and Digital Banking Layers

One of the biggest and most important architectural choices a bank or neobank must make is the differentiation between core banking and the front-end (digital experience) layer. This choice impacts practically all subsequent decisions regarding development of other technologies.

Core banking systems are built with the priorities of stability and correctness rather than agility and speed. They handle the processing and recording of transactions and therefore any failure here impacts customers directly. Traditional core banking systems were built decades ago in many banks and the replacement of them is a multiyear process with high risks and costs.

On the other hand, digital experience layer is a part of the banking software where innovation happens rapidly. Development of new mobile app features or personalization opportunities is possible much faster than modification of the core banking systems provided there is an appropriate middleware architecture in place.

There are two major approaches to the modernization of the banking systems:

1. Progressive modernization is adding modern APIs to the existing core banking system through the intermediary middleware layer. This way of modernization is less risky but also less rewarding since the core of the banking system remains the same.
2. Core replacement is a complete migration of the core banking system into a modern and usually cloud-native core banking platform. This path is riskier but more rewarding and it is usually chosen by neobanks and some other institutions whose legacy core is a barrier to further innovation and business development.

Both approaches to the modernization have their advantages and disadvantages but the choice between them depends greatly on the capabilities of the existing core system.

Regulation and Compliance for Banking Applications

Compliance is not something that can be added to the banking software at the end of the development process. Instead, it impacts the architecture and even data model design from the very beginning.

Banking software development process may involve such regulatory compliance tasks as:

● Know Your Customer and Anti Money Laundering requirements, including identity verification workflows and transaction monitoring for suspicious activity

● Data residency requirements that require certain data to stay in specific jurisdictions

● Creating complete and immutable audit trails for every transaction, change of account details, etc. with the retention period exceeding seven years

● Reporting of the relevant information to the central bank or other regulator

● Consumer protection requirements regarding disclosure and dispute handling

Audit trails deserve special attention since every banking system must log the data about who performed certain actions, when, and from where in the immutable way. This often impacts the decision about database architecture since the append-only transaction logs are preferred.

Data residency is becoming an increasing issue for the regulated institutions in multiple jurisdictions. Institutions planning to use cloud infrastructure must take into account our separate guide on the sovereign cloud architecture, which discusses the issues in greater detail.

Security of Banking Software

Security in banking applications is not just an additional layer of the banking software. It is a security architecture that is incorporated in every aspect of development.

Major security requirements for banking software development include:

● Encryption of the data in transit and at rest using industry-standard encryption algorithms with clear key rotation policy

● Use of Hardware Security Module (HSM) devices to ensure secure generation, management, and storage of cryptographic keys. HSM keeps the keys out of reach of potential attacker that gained access to banking software

● Fraud control mechanisms integrated in the transaction pipeline with velocity checking, device fingerprinting, geolocation checks, and step-up authentication on the basis of risk score calculation rather than post facto fraud monitoring systems

● Strong authentication including multi-factor authentication of customers and privileged access management for employees and administrators

● Regular penetration testing and code reviews conducted by independent third parties because it is a typical requirement of regulators and enterprise banking customers

When choosing the development partner institutions must carefully evaluate its certificates and audit history instead of marketing materials. Our company maintains ISO 27001 certification of information security management, which is the actual proof of our security policy and architecture instead of marketing statement. This is the kind of certificate that every banking buyer must request from its development partner.

Open Banking and API Integration in Banking Software

Open banking regulations in multiple jurisdictions require exposing the information about the clients through the APIs with the explicit consent of the client. This changes the banking software architecture making it more oriented towards the use of APIs.

Consider the following aspects when implementing the open banking:

● Adherence to the existing API standards in your jurisdiction, which reduces the integration overhead with the third parties

● Implementation of the robust consent management solution that logs the information about what data a customer authorized which third party to access and for how long

● Implementation of the rate limiting and API gateway components to prevent negative impact of third-party access on core systems' performance

● Use of strong authentication for the API access with short-term tokens and clear token revocation mechanisms

Open banking also stimulates partnerships between banks and fintech companies that became easier with the implementation of the standardized API interfaces. When evaluating open banking solutions alongside with the overall digital transformation strategy, institutions may find our guide on the fintech software development useful.

Key Features for a Digital Banking App

Expectations regarding the features and functionality of a digital banking application have increased significantly. The essential features of the application today are:

● Real-time transaction tracking with minimal delay between the moment of transaction and appearance in the app

● Mobile check deposit based on the picture captured by the device camera and analysis of it for the fraud prevention

● Peer-to-peer and bill payment functionality with clear dispute mechanisms

● Management of bank cards with the ability to freeze, un-freeze or limit card spending immediately in the application

● Budgeting and spendings analytics

● Authentication based on biometrics with alternative methods for the users with disabilities

● Proactive alerts about unusual activities, low balance, or scheduled payments

Features that make digital banking applications different from the others are not about features themselves but rather about responsiveness and performance.

Development Costs and Timeline

The costs of the project depend greatly on its scope and regulatory requirements as well as on the need to replace core banking system or implement a digital layer on top of the existing one.

These estimates are made for a medium-sized institution or neobank with moderate requirements regarding the regulations. The multi-jurisdictional operations and additional certifications increase the cost and timeline of the project due to compliance validation and security tests requirements, which cannot be sped up significantly.

Choosing a Partner for Banking Software Development

Institution buying banking software development services must consider the vendor far more carefully than other software vendors.

The most important criteria are:

● Experience in development of the software for financial institutions with independent certification

● Independent security certification of the development company like ISO 27001 and the detailed description of the process of its maintenance via regular audits

● Approach to regulatory compliance, which demonstrates the knowledge of the specific requirements of the jurisdiction and type of the financial institution

● Recommendations from the previous projects involving banking customers, particularly regarding the way the partner responded to a production incident, not just smooth deployment of the software

● Hosting and data residency practices

● Realistic and staged roll-out plan, not full replacement of the existing system in one step

Institutions must be careful with the partners not willing to discuss in specific and verifiable terms its security certifications and audit history. The lack of these details is a red flag in banking software development.

AI in Banking: Fraud Detection, Credit Scoring and Customer Support

Artificial intelligence has already become operational in banking industry although it requires careful governance due to the scrutiny it gets as the part of financial decisions.

Fraud detection models monitor transaction patterns in real time flagging any anomalies detected according to spending behavior, device signals, and geographic patterns. Such models usually complement the rule-based models, since regulators usually require the explainability of the decision in the case of fraudulent transactions, and fully opaque model is problematic for that purpose.

Credit risk models use machine learning to estimate the creditworthiness of the customer using wider range of the data than traditional credit score. An institution using such model needs to maintain the proper governance and explainability of the decisions since the lending decisions are subject to fair lending regulations in most jurisdictions.

The use of AI for customer support involves chatbots that help customers with routine requests and routing of the requests to human staff in the more complex cases. The best practice in this area is to define narrow set of requests such as balance inquiries and transaction disputes that the bot handles and provide a clear way to escalate to the human operator for all other requests.

For all three applications the principle of the governance is the same: the AI models in banking must be explainable and auditable since the regulators and customers expect a bank to explain its decisions on the fraud, credit decision, and customer support.

FAQs

Should a neobank develop its own core banking system or license the existing platform?

It is better for most neobanks to license the cloud-native modern core banking platform instead of developing their own, since creation of compliant and robust core banking system is a significant project even for well-funded neobanks. Developing a core is a good idea only for the digital banking layers and API integration.

How much extra time the compliance adds to the banking software development?

Compliance-related development tasks such as audit trails design, security testing, and integration of reporting mechanisms add twenty to forty percent to the usual timeline of similar non-regulated project.

What is the difference between wrapping the legacy core with APIs and replacing it?

The wrapping is preserving the legacy core but exposing it to the digital world through modern APIs via middleware layer. The replacement is changing the whole core banking system.

Why data residency is so important for banking software?

Many jurisdictions have specific requirements about the storage and processing of the banking data for both the specific regulation and general data protection law. Compliance with these laws is required to be able to operate in the jurisdictions.

Can an AI model be used for credit decision without human review?

This depends greatly on the jurisdiction and the specific regulation of the lending decisions. Many institutions still perform human review of the decisions made by the model, and in any case the AI involvement in credit scoring requires the explainability documentation.