Best Core Banking Software. 26 Key Considerations How To Choose or Build One To Kickstart Your FinTech.
The FinTech market is booming and more and more “core banking software” solutions (or “core banking system”, whichever name you prefer) are available for new FinTech start-ups. People are overwhelmed with the choice and therefore I receive dozens of calls and emails every month from clients, our website visitors, former colleagues, and my LinkedIn contacts from the payments service industry asking me “Dmitrijus, what is the best core banking software for my FinTech?” To save my time I decided to write the most comprehensive guide on this topic that you can find online based on my 20+ years of experience in the payments industry and interactions with hundreds of software providers and FinTech companies claiming that they have the best core banking software for EMIs.
In 2009 the European Union, a pioneer in open banking, has opened the transactional banking market to non-bank payment service providers, such as payment institutions and electronic money institutions, which meant that these entities began to offer IBAN account numbers, money transfers via SEPA, FasterPayments, Target2, SWIFT, currency exchange, debit, and prepaid cards issuance, and other money transfer services. Many of these FinTech startups opted for using the existing core banking software solutions as their core platform, some have opted for developing their own. Because of the liberation of the transactional banking market and explosive growth of the number of FinTech startups, since 2015 the new cluster of core banking software for non-bank PSPs has started to emerge. In 2021 most of the payment institutions and electronic money institutions launching their transactional banking business from scratch are opting for the best core banking software for non-bank PSPs, which usually includes a web banking portal and mobile apps which are white-labelled to the PSPs. Opting for the white label solution allows the non-Bank PSPs to launch their products and services in a very short period, without having to spend years and millions of pounds or euros for the development of their own core.
In this article, we discuss the key considerations that non-bank payment service providers (e.g., UK EMIs and PIs) should bear in mind when assessing the merits of different software providers and software packages. However, if your FinTech business is not about payments, this comprehensive guide may be still relevant for you (just check the table of content). As an EMI or PI, you may choose to develop in-house your own core banking software or opt for a white-label solution provided by a third party. Regardless of which one you choose, these principles will remain relevant for you.
How to choose the best core banking software. Technological Considerations.
In this section we will focus on the purely technological aspects of the core banking software, touching upon the pros and cons of the legacy systems, the types of databases that can be used, the different APIs and their role, what ‘microservices’ are and why they are important, types of interfaces, and hosting types.
Legacy platforms – A solution for some PSPs
Legacy core banking systems are still popular among FinTech start-ups because of their reliability and good level of support which, when connected via an Application Programming Interface (API) with the modern front-end and mobile apps, may provide a good solution for wealthier start-ups. For the vast majority (≈ 98%) of start-ups, however, the high cost of such solution poses a significant economic barrier.
Moreover, you should consider the fact that most of these legacy systems have different products and services hardcoded in their core. Therefore, you will have to invest heavily into a proprietary external microservices engine, and the legacy core banking system will act as a mere system of records. Otherwise, you will not be able to develop and roll out new payment methods and products in a timely manner and in some instances never at all.
Example of legacy core banking system architecture
Choice of database – Why is it important?
While there is nothing wrong with using MS SQL, or Oracle databases, the key factor here is license cost, as you will have to pay for development, staging, and production servers, thus your cost is at least x3 of that one server license cost. For example, MS SQL Server Enterprise Edition costs $7,128 per core per annum, three servers will cost you at least $21,384 per annum. Many start-ups are choosing core banking software based on free and open-source databases like PostgreSQL, which has already proven itself in mission-critical, high availability, high volume systems in the financial services sector.
APIs and their role
For any modern transactional banking start-up providing its services and data from any platform, service APIs are mission-critical and can really “make or break” the business. Most modern core banking software engineering teams are opting for the RESTful architectural style of the API as compared to SOAP APIs which is a standard for the legacy systems. SOAP has SSL (Secure Socket Layer) and WS-security due to which in the cases like Bank Account Password, Card Number, etc. SOAP is still preferred over REST. However, REST APIs use multiple standards like HTTP, JSON, URL, and XML for data communication and transfer, so it takes fewer resources and bandwidth as compared to SOAP API. Most REST APIs are HTTP-based, so it helps in ease of development. REST can still make use of SOAP as the underlying protocol for web services because, in the end, it is just an architectural pattern. Any APIs should be developed as stateless as possible, no client state should be maintained on the server.
Taking this further, future core banking software API developers are more likely to use GraphQL, an open-source data query and manipulation language for APIs that was originally developed by Facebook and then made open-sourced and moved to the newly established GraphQL Foundation. GraphQL is designed to make APIs fast, flexible, and developer-friendly. As an alternative to REST, GraphQL lets developers construct requests that pull data from multiple data sources in a single API call, and this is especially important for the core banking software where the different microservices are comprising the core instead of the monolith of the legacy core banking systems (which we’ll discuss in the next section of this article). GraphQL allows clients to define the structure of the data required, and the same structure of the data is returned from the server, therefore preventing excessively large amounts of data from being returned and as a result.
Microservices architecture is the key principle of the best core banking software
Very often modern core banking software is characterised by the specialists as the three-tier architecture which includes the front-end customer engagement layer, the microservices layer sitting in the middle, and the backend which holds the core banking modules. This approach, however, is already at least a decade old. The microservices, each with its own database, coupled with intra-communication, deployment, and container orchestration platform like Docker + Kubernetes is the new core. Each microservice has its own database to ensure maximum autonomy and if one of the microservices fails, others will continue to function. Such architecture provides maximum flexibility that allows payment service providers (PSPs) to be very efficient in how they are building their customer journey, products and services.
As one would expect, very often legacy core banking platforms have business logic built into the core, in most cases it is very hard to expand the current functionality or add an additional one to such monolith. To be able to satisfy the ever-growing needs of the PSPs, there is a need to break the monolith and business logic into different microservices, independent of each other but seamlessly working together. As the result, the business processes and payment methods can be modified or created quickly without touching the core, and very often this can be undertaken by the non-IT personnel.
Technology is going to keep evolving and PSPs need to be able to keep up. Decoupling the core banking system vertically and horizontally with a mindset of plug-and-play provides a strong foundation and PSP can build three, four, or even five floors on top, while remaining technology and payment method agnostic. The use of scaling technology and embedding security in the core banking software must be considered from the outset, all to innovate faster and improve the delivery time of the new products and payment methods to customers of the PSPs while keeping up with the highest standards.
User-friendly, secure, and reliable mobile apps are critical for any PSP engaged in the provision of transactional banking services. Very often such mobile apps are developed using cross-platform development apps like Xamarin, Flutter, Kotlin Multiplatform, etc. This allows IT engineers to build mobile applications using a single code base that works across multiple systems. It helps save them time to write native code across each operating system while acquiring new skills to support every mobile device. Further, the reusable code base enables a timely resolution of bugs and includes enhancements on all platforms in one go.
However, mobile apps developed using cross-platform principles are not suitable for neo-banking apps, and here is why: performance is one of the most important characteristics of an app. Although many factors are involved, as a rule of thumb, if you compare two applications where one is native and the other is cross-platform and both have the same functionalities, the native one will be ever so slightly faster. Very often it is not possible to use elements of the native application interfaces in cross-platform developed applications, which undermines customer experience. Cross-platform applications must adapt their design and functionalities not only to specific devices but also to platforms, which have many differences. As a result, it creates extra work for developers who have to handle specific exceptions for a variety of devices and platform differences, especially with more complicated features.
These issues don’t occur that often in native apps, so developers can focus on solving users’ problems. Every time Google or Apple introduces a new feature for Android or iOS, it takes some time to update cross-platform applications to support this new feature. In native apps, new SDKs are provided with updates much faster than for cross-platform frameworks.
And last but not least, there is always a risk that the cross-platform development app will stop being supported, like happened with Xamarin.
In our experience, we have seen that many modern core banking software solutions for transactional banking are ignoring the demand of corporate customers for a well-designed and intuitive web banking portal. While most private individuals are keen on using mobile apps to access their provider of electronic money and payments, for corporate customers using the web interface on their laptops or desktops is their daily routine. That’s why it is important for the PSPs to have a robust web banking app that works across all popular browsers, offers different user access levels and rights, enables two or even three signatories for the preparation, signing, and execution of payment orders, and can store unlimited statement data, even going 5 years back or more.
Moreover, two-factor authentication for web banking is a must-have. While it is easily implemented in mobile apps using a fingerprint or face ID without compromising customer experience, in web banking, the password and OTP by SMS or OTP generated using a digipass are the two most popular solutions. Additionally, corporate customers of the PSP need to have access to their web banking API to enable their enterprise management solutions such as invoicing and accounting apps to grab safely and securely financial data from the account or upload payment orders via API instead of entering them manually one by one.
Hosting: cloud-native or own servers?
Cloud hosting has become a new norm for the transactional banking service provision, as maintenance of your own hosting centre, which very often has to be PCI DSS compliant, is a very expensive solution. With the development of the fully managed hosting environment by AWS, Google Cloud, Microsoft Azure, and others, PSP should consider the selection of the best core banking software from the angle of cloud hosting and consider regulatory factors (hosting provider may not be available in your country), the existence of fully managed hosting for specific databases and cost. The more flexible the PSP is with respect to the place where it can host its core banking software, the better.
For example, PostgreSQL can be installed and managed in a wide range of operating systems and environments, including FreeBSD, HP-UX, Linux, NetBSD, OpenBSD, OS X, Solaris, Unix, and Windows servers. There is fully managed PostgreSQL hosting available on AWS, Azure, Google Cloud, and DigitalOcean, with high availability and SSH access on the multi-cloud DBaaS. PostgreSQL also offers a lot of flexibility if PSP wants to have it hosted and operated from their privately-owned data centre.
Security is paramount for any core banking software
A secure core banking software or payment system implies an unquestionable commitment to state-of-the-art application security, as this is a clear and consistent objective of the market. Secure core banking demands a vendor organisation managing information security properly and security considerations embedded into their product. A good vendor of the core banking system has implemented an Information Security Management System (ISMS) which covers specific areas and processes within their organisation and the software development processes should be within the scope of their ISMS. Usually, such vendors are following the international standards ISO/IEC 27001 and some also have or will have these management systems certified by an independent third party.
Additionally, for the instances where card issuance projects are managed within the core banking software, PCI DSS certification will be needed to comply with the card scheme rules. PCI DSS will imply quarterly ASV scans, annual audits, and re-certification. Periodic vulnerability and penetration testing of each specific PSP that uses a white-label core banking system should be undertaken upon the rollout of the new features, updates, or significant modifications but not less than every six months. Results of such testing should be provided to the PSP that licenses a white-label solution from the core banking software vendor. It is recommended that third-party IT Security auditors conducted an independent vulnerability and penetration test of the core banking software at least once a year.
Additionally, vendors should have Business Continuity and Recovery Plan in place and periodically train their employees by simulating a breakdown of the white-label core banking software of one of the PSPs that licenses it.
How to choose the best core banking software for EMI. Regulatory compliance perspective
The payment services sector is a highly regulated space and all PSPs are required to have appropriate IT to ensure compliance. This section will discuss several points that should be borne in mind by the PSPs when choosing their core banking software, starting with those that are aiming to ease reporting and ending with those that are essential for compliance with regulatory obligations.
Reasons why embedded regulatory reporting is important
Ease of regulatory reporting is one of the key considerations when selecting a suitable core banking software for non-bank electronic money or payment institutions. Regulators are expecting timely and accurate reporting, and while legacy core banking solutions possess certain functionality for such reporting, many of the newly-developed core banking solutions are seriously lacking in this regard.
When choosing the core payment software, PSPs should consider the ability of such software to produce various reports for a certain period, for example, customer statistics related to their place of residency/incorporation, customer payments turnover, number of payments, number of payments for each payment method, number of payments for local, intra-regional and cross border transactions, statistics on the geography of the incoming and outgoing payments, outstanding average electronic money, the total value of customers funds that have to be safeguarded, the total value of funds on the safeguarding bank accounts, balance sheet, and profit loss statement, ongoing capital adequacy report, etc.
While most European regulators have only a manual submission of the reports, some of them are developing reporting via API, and if your core banking software provider is able to provide automated reporting, this will free up considerable human resources of the PSP and save time.
On an additional note, if the core banking or core payment software does not support a full chart of accounts, general ledger transactions and intra-company accounts (i.e., the PSP cannot keep its own accounts within that core and it records them in a separate accounting software), the PSP cannot effectively manage the regulatory compliance in respect of the ongoing capital adequacy requirement or safeguarding responsibilities, nor produce such reports in a timely manner. We will return to this point in more detail when discussing the operational considerations.
User access rights within the core banking software
Design of the PSP user rights is critical for regulatory compliance so as to comply with the data protection legislation, sensitive payment data protection, ensure proper governance and controls as well as prevent any insider threats. On multiple occasions, we have observed that in newly developed core banking solutions one user with a certain profile was able to onboard the customer, process their payment transaction, approve and remove the red flag of the AML system and send the money transfer order to the bank via API. Such absence of proper governance and control, where four eyes’ principles are not observed, when one user can undertake all these actions without a second user reviewing and approving them, is a serious issue.
Sensitive payment data protection
Another critical matter is that the core banking software user rights should be designed in a such manner that access to sensitive customer payment data is granted only to those within whose duties it is to deal with such information; for example, payment officers or AML personnel. People from marketing and sales should not have access to such data, even if they are using core banking software to send mass-marketing e-mails, SMSs, or push notifications. Customer service personnel should have limited access to sensitive payment data. This could be achieved, for example, by masking remitter/beneficiary’s names when an employee with a customer service personnel user profile is logged in. Sensitive payment data export from the core banking system into csv, excel, or other types of files, or printing should be restricted to authorised users, such as MLRO, Chief Compliance Officer, or CEO.
We have already discussed sensitive payment data protection, but there are other data protection considerations that need to be taken into account. The PSP in question needs to ensure that all information that is stored on its core banking software servers is kept in a form that permits data subjects identification for no longer than is necessary. Furthermore, the PSP must be clear about the length of time that the data will be kept and the reason why the information is being retained. Generally, personal data collected for one purpose, should not be retained once that purpose has ceased.
On the other hand, there are data retention obligations under anti-money laundering (AML) prevention and counter-terrorism financing (CTF). For example, if AML and CTF regulations require the PSP to keep the data for a period of 5 years, once the customer account is closed, the company should maintain the customer’s data for 5 years (after the closure), and erase or anonymise it when no longer needed. It may be impossible to erase the data from the core banking systems that have a full chart of accounts, general ledger, and intra-company accounts, as such erasing may cause erroneous financial statements of the PSP in the closed periods and may affect the current year’s figures. Therefore customers, their data, and payment transaction data should be anonymised when and if necessary via a manual or automated process.
Embedded onboarding and CDD within the core banking software
One of the key components of a modern core banking software is flawless digital onboarding via mobile app or web form. It has become a norm to have a seamless biometric identification built into the mobile app or web form. Most of the core banking software vendors are not providing the service themselves and offering integrations with popular providers.
One of the drawbacks of such integrations is that in order to obtain a full report of the biometric identification, AML, CTF, PEP, and sanctions screening results (which are usually packed with the biometric identification), the PSP user has to login into the biometric identification provider’s portal, which is inconvenient, as it requires searching in one portal and checking that information against the data provided within the core banking software. Therefore, it is important that the biometric identification, AML, CTF, PEP, and sanctions screening results are either accessed via API from the core banking software interface or stored on the core system in the form of pdf or another acceptable file format.
AML and CTF
Anti-money laundering (AML) and counter-terrorism financing (CTF) are very important functions of any PSP. A good core banking software will have a combination of built-in AML and CTF measures and external integration with the providers of relevant databases, that include information on arrests, warrants, and sentences, negative media, etc. Built-in functionality includes the onboarding questionnaire, which allows to: determine the initial risk score of the customer, set initial payment limits (volume and number), and indicate the business/occupation of the customer. In addition to that, the core banking software should keep records on the expiration of customer identification documents, such as passports or ID cards, and remind the PSP users to obtain a new government-issued ID upon the expiration.
Moreover, the core banking software should remind the PSP’s users when to conduct a periodic AML/CTF review of the customer, based on the customer risk level, this could be for example every 2 years for the low-risk customer, 1 year for medium risk, every 6 months for high risk. Every time the transaction is carried out on the account of the customer, the customer must be checked against the AML/CTF databases, and negative media that is furnished by external providers.
PEP and sanctions
Identification of politically-exposed persons and screening of customers against the sanctions list is an important task of PSPs under their AML, CTF, and financial crime prevention obligations. While PEP screening is usually outsourced, the PSP needs to ensure that the PEP database integration that is provided by the core banking systems provider is a reliable source of information. Not all PEP databases are equal, and the best choice is a database that is updated daily by the representatives of the PEP screening provider based in various countries.
While most of the core banking systems providers are offering integrations for the sanctions lists screening, sanctions lists are the open-source information, that can be developed and built into the core banking system by its vendor so that the PSP can save money in that respect. Needless to say that any transaction of the customer and the data points such as the identity of the remitters/beneficiaries must be screened against PEP databases and sanction lists. Moreover, such functionality as appropriate transliteration is a must to spot any parties transactions with whom would be detrimental to the regulatory obligations of the PSP itself.
The risk-based approach and risk scoring of each customer and transaction is an integral part of any PSP’s AML/CTF regime. The purpose of this risk assessment and evaluation is to help with the establishment and implementation of specific policies and procedures which would mitigate identified risks. Each customer and transaction represent a different level of risk related to money laundering, terrorist financing, and other financial crimes. Therefore, various factors need to be considered, which define the overall risk criteria and outline the measures and procedures to be followed while dealing with whichever customer or transaction. An example of such factors could include but not be limited to distribution channels, geography, type of product or service, customer type, transactions value and velocity, etc.
We have observed a unique situation with the modern core banking software or core payments systems offered to start-up fintech companies. Although the risk-based approach is a legal requirement in Europe and is identified by FATF as the centrepiece of an effective AML/CTF compliance program, most of the vendors are neglecting the necessity of this approach and are not supplying this module with their core banking solution. Therefore, PSPs are forced to either develop their own solution or outsource it from another provider, which increases the cost of running the business, delays the launch of the products, and creates the loophole in data protection, especially with regard to the sensitive payment data protection, which we’ll discuss further on.
How to choose the best core banking software. Ease of day-to-day operations and further development
Apart from technological and regulatory compliance matters, the est core banking software must have appropriate modules to carry out day-to-day operations. This should not come as a surprise, albeit many white-label solutions have almost zero functionality for operational management. In this section, we will outline the main considerations that each PSP should bear in mind when choosing a core banking software.
We have already briefly discussed the need and necessity of key integrations of any core banking or core payments software of the PSP with the specialist service providers. Nevertheless, let’s imagine the situation where a PSP has decided to get the cheapest core banking software on the market, which is a mere customer profile and electronic wallet capable of issuing IBAN account numbers. Such a solution will have at least 5 integrations with the outside providers, that will include for example accounting software, biometric identification app, AML/CTF/negative media screening, PEP and sanctions screening, transaction risk scoring. What does this mean technically, apart from recurring monthly expenses for the service that would have been otherwise provided by the core banking software? It means that in most scenarios, the operators of the PSP would need to have 5 additional screens opened on their computer, as the information is not presented in the core banking system, and to access detailed reports, they will have to login into a different portal. It means that all 5 integrations have to be maintained by the IT personnel, and breakage of any of them will effectively halt the company to a stop or delay the provision of services. It means that the personally identifiable data and sensitive payment data are scattered across 5 service providers, and significant resources of the PSP have to be assigned to maintain the integrity of the data, and its protection.
The PSP has to consider how exactly they are going to ensure that the personally-identifiable data and sensitive payment data are deleted or anonymised in the suppliers’ system after the expiration of 5 years’ period from the termination of the relationship. 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. Another aspect to consider is the potential breach of third-party provider systems, if Facebook and LinkedIn, and even the CIA’s Center for Cyber Intelligence can be breached, what kind of assurances the PSP can have on the integrity of the data and IT systems security of their service providers?
Development and expansion
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.
The first one is that any such system will be limited in respect of the integrations with the third-party service providers, be it AML/CTF screening, or integration with SEPA or Faster Payments connectivity provider. 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 PSP cannot expect that the core banking system or core payments system vendor will have integrations with all PSP’s banking partners, thus such integrations will be paid for by the PSPs, and if it not a fixed pricing, and hourly based, things can get out of hand very quickly, and run into tens of thousands of pounds.
The third is the development of additional payment methods, products, and services. Similar to the integrations with the third-party providers, this requires significant investment by the PSP into the core banking software that they don’t even own.
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.e. when the PSP cannot keep its own accounts within such core and is recording these in separate accounting software. 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. have to be entered into the accounting software. After that, the reconciliation of the safeguarded client’s funds has to be carried out, and excess funds removed from the safeguarded bank account. 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. In addition to that, the company will have to employ at least one dedicated account and one reporting specialist which together may cost over £100,000 annually. Therefore, the core banking software that does not support a full chart of accounts, general ledger transactions, and intra-company accounts is not a good choice for any serious electronic money and/or payment services start-up.
Internal notifications system within the core banking software
One of the key operational features of any e-money/payments business is a system of internal notifications within the core banking software. 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.
Customer notifications system
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. Notifications of the transaction should be optional and is a good method for the prevention of financial crime and hacking of the e-wallet/payment accounts. 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 .jpeg, .pdf, or .word. 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. Any exchange of information and/or documents between the PSP and the customer (for example, during the enhanced due diligence) should be handled solely within the mobile app and/or web application (i.e. secure communication channels), otherwise it will be impossible for the PSP to comply with the data protection legislation and sensitive payment data protection regulations. Therefore, mobile apps and web applications must have the functionality for the secure transfer of files, regardless of their type.
Ease of migration
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.
How to choose the best core banking software. Cost considerations and contract considerations when buying software
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.
Contractual conditions for data protection
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. all of it a prerequisite for the compliance of the PSP with its obligations and ensuring appropriate customer protection.
Cost of additional IT development
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. With the average cost of API integration of £7,000, plan and budget at least 6 additional integrations with the banking partners, FX, and payment service providers in the first year. 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.
Cost of additional services
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.
Imagine a situation where you acquire the white label core payments system for up to 10,000 clients with a monthly fee of £7,000, then you added a biometric identification app with a fixed monthly fee of £1,000 and £2.50 per check, then you added AML/CTF/negative media provider with a fixed monthly fee of £2,000 and £0.10 per check, then a PEP/sanctions screening provider with a fixed monthly fee of £1,200, and a risk scoring app with a £3,000 fixed monthly fee. You will be additionally paying in just fixed monthly fees of £7,200 in additional services, without which your PSP will not be able to function. 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 …
How PSP Lab can help
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.