Fintech Software Development: Compliance, Cost and Choosing a Partner

The development of fintech solutions is not the same as web applications, e-commerce or any other software product. The addition of the payment functionality to any software product transforms it into a fintech solution and introduces some regulations, security measures and requirements to development process. The functionality which would be implemented in two weeks in a regular software product may take six weeks to implement in the context of fintech software development due to the specificities of fintech development such as tokenisation and audit logging.

This article is aimed at founders of fintech startups and financial product managers who need to understand the fintech software development in order to scope the project, hire a team or choose a development partner. We will provide information about regulations, security architecture, fintech products types, integrations, estimated cost and timeline, selection criteria of fintech software development company, application of AI in fintech software development and uptime considerations.

What Is Involved in Fintech Software Development

Fintech software development is the development of applications that perform financial transactions, process financial data or make financial decisions. This includes both consumer-oriented applications like neobanks and payment wallets and back-office systems like ledgers and reconciliation engines or infrastructure layers that connect fintech applications with banking infrastructure or credit bureaus.

There are three major differences of fintech development from development of any software solutions. Firstly, fintech applications deal with regulated data – card numbers, bank account details, income details, identity documents etc. Secondly, any change of the system state that involves money is subject to auditing. Thirdly, fintech software requires reliable uptime and correctness of the operations because the bug in the fintech application may cause financial problems.

Fintech development includes four layers of functionality – core application layer (product itself), integration layer (integrations with banks, card networks, payment processors, credit bureaus etc.), compliance layer (KYC, AML and audit logging) and data layer that is specifically designed with the aim of providing maximum security and minimum convenience.

Regulatory Framework: PCI DSS, KYC, AML, PSD2

Regulations are not the checklist that should be followed after the development of the product. Regulations influence the architecture of the product from the very beginning. Let's discuss what each major framework means in practice.

PCI DSS (Payment Card Industry Data Security Standard) is the standard that should be applied to any system that stores, processes or transmits cardholder data. It includes requirements to the network segmentation, encryption of card data in transit and at rest, restricted access to the cardholder data on a need-to-know basis and regular vulnerability scanning. In practice, most fintech products do not need full PCI DSS compliance because of using tokenisation provider (usually the payment processor's vault). That lowers the compliance and audit load of the product. But you should take it into consideration from the very beginning of the architecture development, not as a patch later.

KYC (Know Your Customer) is the identity verification process that should be performed before allowing a customer to transact. In most cases it means identity documents capture, checking of the customer's liveness and sanctions and politically exposed persons (PEP) list screening. KYC requirements depend on the product and jurisdiction. KYC process of the lending product is usually more complicated than KYC process of the prepaid wallet product. You should decide whether KYC process is to be implemented in your product by yourself or is to be provided by a third-party identity verification vendor. In most cases KYC process is provided by a third party.

AML (Anti-Money Laundering) includes the process of ongoing monitoring of the customers after onboarding. It includes transaction monitoring, sanctions list screening on an ongoing basis and suspicious activity reporting (SAR). From the engineering point of view it means that the transaction data model of your product should be capable of supporting rule-based and behavior-based monitoring, and your team should have the workflow for the suspicious activity reports filling.

PSD2 (Payment Services Directive 2) is the regulation of the European Union that is relevant to any product that is processing payments for EU users. The major engineering implication of PSD2 is the Strong Customer Authentication (SCA) requirement that demands two-factor authentication for most electronic payments and

Open Banking access that implies the mandatory availability of the account data via regulated APIs to licensed third parties. If you are developing a product with EU exposure, PSD2 compliance will influence your authentication flow and bank data access from the very beginning.

If you make a mistake in any of these processes, regulators may fine, suspend or completely shutdown your product. A development partner that has no experience with these frameworks is a serious risk, despite high engineering skill of the team.

Security Architecture for Financial Data

Security of financial data in fintech software is the question of architectural design, not adding some extra features to the application after the development. There are three major components of the baseline of fintech security architecture.

Encryption of data in transit and at rest. In-transit data encryption should include TLS 1.2 and higher for all API communications. Encryption at rest implies encryption of sensitive fields in the databases using a dedicated service (AWS KMS or HashiCorp Vault) for the management of keys, rather than storing them with the application code.

Tokenisation is the replacement of sensitive data (card numbers, bank account details etc.) with non-sensitive substitution (token). Tokenisation is the main method of avoiding full PCI DSS compliance. In this case, you store tokens issued by the payment processor rather than card numbers in your system.

Audit logging – logging of all actions that involve financial data or account states: logins, transaction creation, balance change, permission change, data access by internal personnel. These logs should be immutable and kept for the period defined by the regulation (usually from five to seven years depending on the jurisdiction). Logs are usually required by regulators as the first step and should be available from the very first release.

There are other components of the advanced fintech security architecture including role-based access control (RBAC) with least privilege principle, regular penetration tests, incident response plan documentation and separation of production data from staging and development environments.

Types of Fintech Products (Payments, Lending, Wealth, Neobank)

Fintech products are quite diverse and vary in complexity from product to product.

Payment products like wallets, payment gateways and merchant checkout tools are moderate or highly complex products. The core functionality of such products includes integrations with card networks or payment processors, settlement and reconciliation, dispute and refund workflows.

Lending products like personal loans, BNPL and SME lending are highly complex fintech products. In addition to the payments infrastructure, these products include credit decisioning, integration with credit bureaus, loan servicing, repayment schedules, late fee calculation, collections workflows and state-by-state/country-by-country licensing of the product.

Wealth and investment products (robo-advisors, brokerage apps, portfolio tools) are also highly complex products especially if the product includes real-time market data, trade execution and custody of client assets.

Neobanks (digital banking products) are the most complex type of fintech products as they combine payments, lending and sometimes wealth products under the umbrella of a single banking or e-money licence, either owned by the company itself or provided through BaaS (banking as a service) provider. Neobank product build essentially means solving of the regulatory and architectural challenges of the three above mentioned products at once.

Complexity ranking, from low to high: payment gateway integration, merchant payment tools, consumer lending apps, wealth and investment platforms, full neobank builds.

Core Integrations: Payment Gateways, Banking APIs, Credit Bureaus

No fintech product is built from scratch. Integrations consume large part of the efforts during the development process.

Payment gateways and processors (Stripe, Adyen or any regional equivalent) process payments, provide tokenisation and solve the majority of the PCI DSS compliance for you. The choice of the payment processor is the matter of compliance and cost, not the technology, since processor fees and supported markets differ significantly.

Banking APIs integrate your product with bank accounts and provide the following core functionality: account verification, balance checks and funds transfer (ACH, wire transfer or local rail depending on the region).

Credit bureau integrations (Experian, Equifax, Transunion or regional bureaus) are necessary for the lending products in order to get credit report and credit score as the part of the underwriting process. Such integrations usually require the fintech company itself, not just the development partner, to hold a data use agreement with the bureau.

Other common integrations may include identity verification vendor for KYC process, fraud detection platform and accounting or ledger systems for internal reconciliation.

Fintech Software Development Cost and Timeline

Fintech software development cost and timeline are significantly different from product to product. In the table below we provide approximate ranges for MVP and first scalable version, not the final cost and timeline.

Such costs imply usage of well-known third-party providers for identity verification, payments processing and credit checks. It is the usual approach for fintech products.

Choosing a Fintech Software Development Company

Wrong choice of the development partner for your fintech product may cost you much more compared to wrong choice in the majority of software categories, since compliance and security mistakes usually become obvious only after the product is launched and often during the audit or review by the regulator. Use the following checklist when choosing a development partner.

• Direct, verifiable experience with PCI DSS, KYC or AML implementation, not just the knowledge about the frameworks
• Prior projects in your specific product category (lending, payments, wealth or neobank), since compliance patterns are different between them
• Documented secure development lifecycle (SDLC) including code review, dependency scanning and penetration tests practices
• Will to sign data processing agreement and clear description of the way they handle the sensitive data in development and staging
• Experience of integrations with your intended payment processor, banking API and credit bureau
• Ability to implement audit logging and reporting from the very first release, not as an add-on later
• References from fintech clients who have passed a compliance audit or regulatory review with the product developed by the vendor
• Clear post-launch support model, since the fintech products imply ongoing compliance and monitoring responsibilities that do not end with the launch of the product

A development partner that cannot speak about how they handled tokenisation, audit logging and compliance framework implementation in the previous fintech project is a red flag, despite the quality of their portfolio.

AI in Fintech: Fraud Detection, Credit Scoring, Risk

Nowadays AI is the standard practice in some fintech functions although its use varies in its accuracy and appropriate use in different cases.

The most developed AI fintech use case is fraud detection. Machine learning models analyze transaction patterns in real time and flag transactions that appear to be anomalies using such features as transaction velocity, device fingerprinting and behavioral biometrics. Such systems are quite effective in detecting known fraud patterns, but require continuous re-training as fraud tactics constantly evolve.

Credit scoring implies machine learning based assessment of creditworthiness using such factors as cash flow patterns, utility payments and transaction history alongside traditional credit bureau data. It allows to expand the access to credit to such borrowers that lack conventional credit history. But it also implies serious regulatory concerns related to fairness and explainability. Most jurisdictions demand a possibility to explain the adverse credit decision which excludes full black box models from this category.

Risk and transaction monitoring for AML purposes increasingly often use AI to decrease the number of false positives during the suspicious activity detection since rule-based systems generate too many false positives.

But in all cases of the use of AI in fintech, there is a common caveat – models require continuous monitoring for the accuracy and bias. And in case of regulated use cases like credit decision making, explainability may be a legal requirement, not a convenient option.

Building for Scale and Uptime

Financial applications have higher expectation of uptime compared to most software categories because in case of downtimes users won't be able to access their money. There are several architectural practices that fintech systems with high availability should follow.

Redundancy across availability zones or data centers provides protection from a potential infrastructure failure that may bring the entire application down.

Idempotent transaction processing guarantees that the retry of the transaction, a common case of the network failure, will not lead to double charge or transfer.

Asynchronous processing and message queues help to decouple time-critical user interactions (payment initiation for example) from time-consuming back-end operations (settlement or reconciliation), so a slow back-end system won't negatively affect the user experience.

Circuit breakers around third party integrations help to prevent the cascade failure in case of a failure of payment processor or credit bureau integration.

Real-time monitoring and alerting systems based on service level objectives for transaction success rate and latency allow to catch any system degradation before the outage.

That is what makes fintech product capable of handling real transaction volumes as opposed to just demo one.

FAQs

How long does it take to build a fintech app?

A simple payment or wallet product typically takes three to five months for the initial version. Lending and wealth products generally take six to twelve months, and a full neobank build can take ten to sixteen months, depending on the number of markets and integrations involved.

Do I need a banking license to build a fintech product?

Not always. Many fintech products operate through a banking-as-a-service partner or an existing licensed institution rather than holding their own license. Whether you need a license depends on the product, the markets you are operating in and your desire to control the underlying financial infrastructure.

What is the difference between KYC and AML?

KYC is the identity verification process that is performed during the user onboarding process. AML is the process of ongoing monitoring of transactions after onboarding to detect suspicious financial activities. Both processes are usually mandatory and relate to different steps of the user lifecycle.

Can I avoid full PCI DSS compliance?

Yes, in most cases. Using payment processor's tokenization and hosted card capture services allows to avoid PCI DSS compliance in most cases. But you will still have to comply with some requirements (SAQ A and similar).

How accurate is AI-based credit scoring?

Accuracy of AI credit scoring depends on the data and the model. But AI credit models can extend the credit access to the borrowers that lack traditional credit history. Also, these models require continuous validation of bias and accuracy. In most regulated markets, an adverse credit decision should be explainable to the customer.

What should I prioritize if my budget is limited?

Prioritize compliance and security architecture over the feature richness of the product. Fintech application with a smaller number of features but with good KYC, encryption and audit logging is launchable and defensible. An application with a bigger number of features but with poor compliance and security foundations is a risk that will require costly fix-ups to be scalable.