Core banking software design

The result was these earlier core banking systems were monolithic in style, and were exclusively designed to run on expensive mainframes, which were the only machines capable of handling the number of client-server sessions required to service all branches belonging to a given bank. The fact that many banks today still run these systems is testament to their success. This being said there is an important trade-off in that these systems are incredibly expensive to run, especially given that they have to be sized for peak processing, which is typically end of month reconciliation, leaving expensive capacity idle for large periods of time.

Unfortunately for banks still encumbered with mainframes, not only are they expensive to run, the cost of change is also high. Compounding this problem, banks are facing increasing pressure to reduce cost. These systems addressed many of the issues that the banks were experiencing. They had parameterizable product engines, making change cheaper and less risky. They were generally written in more modern programming languages and deployable into application servers which paved the way for the banks to ditch their expensive mainframes, however, these applications were generally stateful, and relied on session management, making it difficult to scale in any way other than vertically.

Whereas this new wave of core banking systems addressed a number of the challenges banks were having, some key pain points remained.

These systems still largely use batch based processing and are monolithic in style, and since they were no longer tied to the expensive yet effective mainframe, they can actually be observed to be less resilient and performant when compared against their predecessors.

This could explain why the third generation struggled to take hold, whereas there has been traction up to the tier-2 banks, they have failed to penetrate the tier-1 market in a meaningful way. This caused a problem for the larger banks as they struggled to progress their core transformation projects. The result is banks can rely on more modern products to solve some of the shortcomings of the legacy core, however the downside is that there is an increased operational complexity and integration challenge.

Additionally, the proliferation of these tactical systems causes data silos which lead to additional overheads such as data mastery concerns as well as data provenance, reconciliation and attestation concerns. Some banks have gone down the route of installing software directly onto the mainframe that can expose previously difficult to extract data via modern APIs. The advent of PSD2 and open banking led to a number of high profile implementations of such an approach, however there is a dangerous trade-off in that since the underlying systems lack the elastical scaling properties to handle the resulting volatile workload volumes, banks could inadvertently trigger a DDoS attack on their on core systems.

The result is that the larger banks have been able to survive by modernizing the stack around a legacy core. Whereas this may work for some time, we have only delayed the inevitable: there is only so long a bank can survive with a dying core.

The more that is pulled out of the core the more we bleed complexity into the mid-tier which causes data silos, and increases overall system fragility. The cracks began to show in the wake of the global financial crisis as the banks were faced with a difficult challenge in that they had to both drive the costs of their IT infrastructure down to allow them to maintain competitive banking products in the market, as well as having to adapt to shifting consumer expectations and increasingly stringent regulator demands.

A notable example of the latter being the introduction of the third installation of the Basel accord, Basel III, which places increasing demands on banks to adapt their core systems in ways that seem to directly clash with the traditional model of end of day batch style processing, such as the requirement of intraday liquidity management. All of a sudden the banks found themselves facing two key challenges that seemed to conflict with each other. To drive the cost of their infrastructure down they needed to get rid of their mainframes and run on leaner infrastructure which would lower the glass ceiling on the amount of processing power in the system.

At the same time, to adapt to regulatory changes they had to increase the frequency of their batch processing jobs, which would require more processing power. Compounding the problem, core banking systems are often designed in such a way that they can only run when the core ledger is closed. There are a number of reasons this makes sense, such as to avoid resource contention between batch processing and online traffic, as well to ensure transformations are run on a stable static data set.

Given that our traditional model of banking was only open for business 9am - 5pm, shutting the core made perfect sense for early generation systems. This comes with its own complications as we add considerable complexity into the system, we find ourselves building a bank within a bank to handle stand-in and having to jump through hoops to fold in the stand-in ledger at the start of the next banking day.

The net result is running the same batch based operations throughout the banking day is often not feasible. Fortunately for the banks, there is hope. We are dealing with a common problem that exists in many domains both within and outside of financial services, a problem that begins to be addressed with a microservice based architecture. In such an architecture each part of the system can dynamically scale in and out, enabling the application to elastically adapt to whatever processing needs you can throw at it whilst keeping non affected parts of the system scaled down, ensuring the overall footprint and as a result cost of the system remains low.

As a result a microservices based architecture paves the way for a scalable, and real time focused core banking system. So, why do the third generation cores simply not refactor their existing systems, splitting up the monolith into a microservices based architecture?

To answer this question it helps to look at some of the key benefits of monolithic architecture. A monolith has a single physical clock, and therefore easy access to a single global total ordering. Having a total ordering makes ensuring correctness in any given request relatively straight forward.

Fiserv, Inc. NASDAQ: FISV has one of the largest banking solution providers in the United States, delivering solutions and services more quickly and efficiently, creating a unified cross-channel customer experience. Finacus is a banking solutions and payment systems partner for over financial institutions.

Their offerings include FinCORE, a fully browser-based and modular core banking system, and an Aadhar-based eKYC know your customer process for opening new accounts without physical upload of ID and address proof documents. Address : 3i Infotech Ltd.

Websoftex Microfinance Banking software is a customized tool for managing your co-operative society of any type. Address : Websoftex Software Solutions Pvt. JMR Infotech is an industry leader in banking and related technologies. Our core banking solutions help in identifying potential risks related to different banking processes and measure their impact on overall performance.

DataMate is a web based, multi-user, multi-currency and real-time, on-line Centralized Banking System that enables retail, consumer, commercial and transaction banking delivered across channels such as the branch, ATM, Internet, mobile, interactive voice response IVR , and SMS banking.

Address : No. CSI NuPoint is a core banking platform with cloud-based architecture that eliminates hardware and software expenditures. Manage everything from loans to fraud detection and risk, customer engagement, transaction processing, and business intelligence and analytics. TM Systems AutoBank is a proven core banking system with a track record of more than 25 years, and is being utilized in more than Banks. Plug-and-play to build the bank you need today. Lower your costs, reduce IT burden, manage regulatory demands and easily launch new products with FIS.

How such notifications will be delivered to the suppliers and how the PSP will control the completion of deletion or anonymisation of data. Such processes will require significant human resources and IT development , and based on our observations, such personally identifiable data and sensitive payment data protection, deletion, and anonymisation are largely ignored by the PSPs and their suppliers. Moreover, apart from finally deleting this data, all of it should be mapped and the register with its designation should be updated on an ongoing basis.

Any electronic money institution or payment institution that is anticipating getting a newly developed core banking system or core payments system should consider several important points.

Therefore, the PSP will be forced to either go with the flow and launch with those providers that are already integrated or pay for the integration that they require. The second one is necessary integrations with the banking or payment service providers. The third is the development of additional payment methods, products, and services. The fourth is considerations of expansion, related to the growth of the PSP and the significant increase of the load of the core banking software.

Would the vendor be able to cope with it, are they conducting load testing, can their database and hosting arrangement support the additional load? All these questions need to be considered before choosing the provider of a white-labelled core banking or core payments solution.

We have already discussed the issue of when the core banking software does not support a full chart of accounts, general ledger transactions, and intra-company accounts, i. But what does that mean on a day-to-day basis for the PSP? It means that there is a need to have an accountant, whose major role is data entry at the end of the operating day — all information on customer funds inflows and outflows, earned fees, bank expenses, etc. The accountant also must ensure that all company expenses are entered for that day as well.

After that, the ongoing capital adequacy report must be generated to ensure that the PSP complies with the capital adequacy requirements. All of these must be carried out once the operational day is over. How about a service that does not have a cut-off time, for example, the card-issuing programme of the PSP? What would be the cut-off time for the card transactions of the customers? An alternative route will be the automation of data export from the core banking system into the accounting system, but it requires investment and permanent checks that all data was exported correctly.

What if the company has hundreds of thousands of transactions daily? Manual entries are no longer viable, and the accounting software will be swamped with records. How reliable is such a system and how much time it will take to produce regulatory reports? Apart from the fact that such PSP cannot effectively manage the regulatory compliance in respect of the ongoing capital adequacy requirement or safeguarding and producing reports in a timely manner, the management of the company would not be able to understand the performance of the company with a few clicks.

The purpose of such a system is to notify core system operators of certain actions they need to undertake, for example, notification of the high-risk score assigned to the transaction should reach transaction risk monitoring specialist and by clicking on the notification, the system takes him to the details of the transaction, and specialist can ever approve it, reject it, or refer to the higher management.

This is much more productive than periodically refreshing the screen with the ledger of transactions. Many PSPs are implementing such notifications using external messengers like Slack or Telegram, but usage of external systems undermines the security of the core, personally identifiable data, and sensitive payments data.

Many PSPs are using external customer management software for their sales and marketing, but as we have discussed, this exposes the company to potential data breaches and operational complexity when it comes to the deletion or anonymisation of personally identifiable information and sensitive payments data. A good, modern core banking or core payments software must have a built-in notifications system that can be used to promote products and services to different groups of clients via push notifications or e-mail and provide notifications of the transactions via push notifications as well.

The core banking system should be able to create a notification action based on the type of clients, their location, their spending patterns, their turnover, etc, thus creating an effective marketing campaign that will not be too intrusive and target the audience with precision.

The marketing can be taken further, for example, if the company is providing POS acquiring services and at the same time providing electronic money services, PSP can advertise the location of the merchant via push notifications to the e-wallet holders that are located close to the merchant.

With such external notification systems, marketing and remarketing methods are limited only by the imagination of the PSP and data protection legislation. Secure and practical storage of documents is one of the fundamental functionalities of a good modern core banking software, for without such functionality it would and will be hard for the PSP to comply with the regulatory requirements.

Documents cannot be embedded in the core banking software; rather, they should be stored in the same location where the core system is hosted , and the core system just contains the links to them. The user interface of the core banking system should be able to open the stored documents quickly regardless of the type of file stored, be it. There should be a preview option available, where possible, in order to save the time of the PSP operators while navigating in the customer profile and searching for a relevant document.

Therefore, mobile apps and web applications must have the functionality for the secure transfer of files, regardless of their type. There might be times when the PSP needs to migrate from their current core banking or core payments solution to another one, be it another white-labelled solution or their own. When choosing the core banking solution provider, PSP needs to assess the ease of potential migration , how the relevant client files, communication records, transaction records can be exported, in what format, how they can be uploaded into the new core systems, etc.

PSP should ensure that the core banking software licensing contract contains the clause under which the vendor undertakes to assist the PSP with relevant data export and migration. Under no circumstances the PSP should enter into any agreements that are preventing data export or complicate migration. The agreement for the licensing of the white-label core banking software should be adhering to the regulatory obligations whilst at the same time taking into account the interests of the PSP.

To accommodate these needs, it is important to pay attention to the clauses implemented within the agreement. Quite frankly, vendors are mostly on the lookout for their own interests and PSPs can sometimes miss key issues.

Therefore, in this section, we will provide a brief overview of the key considerations that should be kept in mind when concluding the agreement with providers of the core banking software. Entering into the agreement with the third-party provider to supply the core banking or core payments software requires careful consideration of the agreement provisions. One of the key considerations is data protection regulations — the vendor must agree to comply with the data protection legislation applicable in the country where the PSP is licensed, therefore specific agreement in respect of data protection must be signed, implemented, and followed at all times by both the PSP and the vendor.

Depending on the location of the vendor and the PSP, such agreement may be in a custom form or the form of standard contractual clauses. In any case, it should clearly outline the responsibilities of the parties, handling of data, transfer of information, purposes of the processing, possibility of employment of third parties, etc. PSPs should never underestimate the costs of additional IT development that may be required to expand and develop their business.

With the current exorbitant hourly IT development rates, try to fix the rates for at least 3 years with a clear distinction between the hourly fees of the system architect, business analyst, senior developer, and junior developer with limited instances when they can be increased. Where and when possible, try to obtain a fixed price for a certain project, be it API integration or a new payment method, as with hourly rates things can quickly get out of hand.

Otherwise, you will have to hire additional personnel to handle orders manually. The cost of integrations is small compared to the human mistakes when and where manual processes are involved and the salaries of additional employees that you will have to pay.

Very often PSPs underestimate the cost of additional services that are not provided within their selected core banking or core payments software, and when these costs start to pile up, suddenly their budget for supporting applications operations becomes higher than the core banking software fees. And the cost does not end here, as we already discussed many constraints related to data protection and sensitive payment data protection. It will be hard to quantify the additional IT development and human resources cost that will be needed to comply with the data protection regulations.

Therefore, when choosing the right core banking system for you, account for all additional services that you will have to pay for. Maybe it makes sense to get a more expensive one, which has built-in at least part of the functionality …. During our practice we have reviewed dozens of solutions that are on the market- we know what will work and what does not.

PSP Lab can assist you in either developing or choosing the best core banking software for EMI available on the market. Moreover, we can assist you to negotiate the best possible terms whilst ensuring that the agreement with the core banking software provider is adhering to the regulatory requirements.

Best Core Banking Software. December 21, Dmitrijus Apockinas Financial Technology. Contents hide. Technological Considerations. Regulatory compliance perspective 2. Ease of day-to-day operations and further development 3.

Cost considerations and contract considerations when buying software 4.