Open source core banking for fintech products

The fintech owns every key and secret that protects customer data, including database credentials, tenant connection settings, API keys for payment and KYC providers, TLS certificates and encryption keys for data at rest. Fineract does not decide how these are stored, so the fintech must choose a secrets manager or key management service, set rotation schedules, and restrict who can read or export values. The FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to encrypt customer information in transit over external networks and at rest, so the key lifecycle must be documented as part of that encryption control. Confirm with your implementation partner where secrets live, how they reach the write, read and batch instances, and how a key compromise is contained across tenants.

A fintech needs multi-factor authentication for every person who can reach an information system, and stronger controls for privileged access. The FTC Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing any information system. For a self-hosted Fineract platform, privileged access includes:

• Administrative logins to the Fineract tenant console and the tenants database
• Direct database access to PostgreSQL, including replicas and backups
• Kubernetes or host access used to run Liquibase migrations or batch jobs
• Service accounts used by integrations

Each group needs named accounts, approval for elevated rights, session recording where possible, and periodic review. Ask your partner which identity provider enforces MFA, how break-glass accounts are protected, and how direct database changes are blocked outside approved change windows.

The fintech must log the activity of authorized users, and keep those logs long enough to answer audit and incident questions. The FTC Safeguards Rule at 16 CFR 314.4 requires logging of authorized user activity. For Fineract, the log set usually covers:

• Authentication events and failed logins, with tenant identifiers
• Loan, savings and client changes made through the APIs, including the acting user
• Product configuration and accounting rule edits
• Batch job runs, reversals and end-of-day adjustments
• Database and infrastructure access

Logs should be centralized, protected from edit by administrators, and time-synchronized. Retention periods come from your regulator and your own policy, so confirm them before design. Confirm whether your partner ships these logs to a separate, write-once store.

The fintech must treat product configuration, accounting rules and code as controlled changes with approval, testing and a record of who changed what. The FTC Safeguards Rule at 16 CFR 314.4 requires change management procedures. In Fineract, a loan product or savings product change can alter interest, fees and ledger postings, so it deserves the same review as a code release. Define who may propose and approve changes, keep product definitions in version control where possible, test changes in a non-production tenant first, and record the deployment that applied them. Ask your partner how configuration is promoted between environments and how an emergency change is reviewed afterward.

Partner data isolation is an ownership item because Fineract routes each request by tenant, and the fintech must prove that a partner cannot see or change another partner's records. Fineract is multi-tenant: API requests carry a Fineract-Platform-TenantId header, and tenant connections are configured from a tenants database, according to the Fineract README. The fintech should verify that the tenant header is enforced at the gateway, that front ends cannot send arbitrary tenant identifiers, that each tenant's database access is limited, and that tests cover cross-tenant requests. Decide whether partners share a database instance or get separate databases, because that choice changes backup, restore and breach scope. Ask your partner for the cross-tenant test cases they run.

The security common criteria CC1 to CC9 apply to every SOC 2 report, and the fintech must map its controls to them whether or not it uses the other trust categories. SOC 2 examinations use the AICPA 2017 Trust Services Criteria across five categories: security, availability, processing integrity, confidentiality and privacy. A SOC 2 Type 1 report describes the system and the design of controls as of a date, while a Type 2 report adds an opinion on operating effectiveness over a period. DeployOpen prepares systems, controls and evidence for assessments but does not issue SOC 2 reports; an independent CPA firm does. Ask your auditor which categories they expect for your scope, and map the key, MFA, logging, change and tenant controls above to the criteria before the examination period starts.

The fintech pays for most ongoing security and audit work, and the cost recurs because controls must operate every day. A one-time build covers secrets design, identity integration, logging pipelines, change workflow and tenant tests. Recurring costs include access reviews, log storage, key rotation, patching, penetration testing and the auditor's evidence period. The FTC Safeguards Rule at 16 CFR 314.4 requires annual penetration testing and vulnerability assessments at least every six months unless continuous monitoring is in place, so testing is a recurring line. DeployOpen can plan, harden and support the platform and run security testing under a written scope, and retainers cover continuous testing. Ask any partner for a quote that separates one-time build, recurring operations and audit preparation.

A small team can run these controls alone only if it has skills in identity, database administration, Kubernetes operations and compliance evidence, and enough people to cover on-call and reviews. The work splits into design, operation and evidence, and each needs a named owner. Keys, MFA, logging, change control and tenant isolation all touch the same platform, so gaps usually appear at the boundaries between teams. Many fintechs use an implementation partner for the initial design and hardening, then keep operational ownership in-house or under a retainer. Confirm your team's coverage for each control in writing before the first production tenant goes live.

The cost is driven by the work around the software, not by a license fee, because Apache Fineract is licensed under Apache-2.0. The main components are product configuration (loans, savings and fee rules), the front end and integration build, the infrastructure you run it on, testing, and ongoing support. Fineract's own README warns that a production deployment can be complex, costly and time-consuming, and that organizations may pay a vendor for deployment and maintenance. Infrastructure and support recur each year, while configuration, integration and testing are largely one-time. Ask any partner for a quote that splits these components and names who pays for each, including your internal staff time.

Duration depends on how many products you launch, how many channels and tenants you connect, and how much of the KYC, payment and reporting integration you need before go-live. No duration figure is given here because the scope varies widely. A fixed scope, agreed in writing before work starts, is the most useful way to fix a timeline. Ask the partner to break the plan into product configuration, integration, testing, security evidence and cutover, and to show which steps depend on your own teams, such as legal sign-off on loan terms or access to your cloud accounts.

A team with strong Java, PostgreSQL, Kubernetes and banking domain skills can build parts of it alone, but the project needs all of them at once. The Fineract project does not provide a comprehensive production deployment guide, so your engineers will write much of the runbook, backup, batch scheduling and upgrade procedures themselves. Quarterly releases mean the upgrade work recurs. Before deciding, list the skills you hold in-house, the ones you would hire, and the ones you would buy for a fixed period, then compare that list with the scope you agreed internally.

The partner needs decisions and access from your organization before engineering can begin. Expect to provide:

• Written product definitions for loans, savings and fees, with accounting rules agreed by finance.
• Tenant design: which partners or entities each tenant serves.
• Access to the cloud accounts, data center or air-gapped network where Fineract will run.
• Sample KYC and transaction data for testing, with privacy controls agreed by your data protection lead.
• Named owners for security approvals, change approvals and go-live sign-off.

Missing decisions in these areas are the most common reason a fixed-scope project changes after it starts.

Fineract is headless and exposes REST APIs without its own user interface, so you choose a front end. The Fineract README points to the Mifos X web application as the front end used in its Kubernetes example, which makes it a practical starting point for staff operations. A custom front end fits better when your customer journeys, mobile flows or partner channels differ from what Mifos X offers. Ask the partner to show how each option handles your roles, approvals, customer-facing screens and API versioning, and to estimate the maintenance effort of each choice in writing before you commit.

Design events around the business facts your downstream systems need, such as a loan disbursed, a repayment posted or a savings account closed, and give each one a stable identifier and schema version. Consumers should tolerate duplicate and out-of-order messages, and the reconciliation process should compare event counts and balances against the general ledger. Define retention, access control and encryption for topics that carry customer data. Ask your partner how events are produced from Fineract (through its APIs or database changes), how failed messages are replayed, and who approves changes to event schemas.

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and it runs security testing and prepares controls and evidence for compliance assessments. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask for a written list of deliverables, the evidence each one produces, and the auditor's requirements you must confirm with them directly before work starts.

The fintech keeps decisions and accountability that a partner cannot take over. These include approving access to customer data, owning the risk register and the regulatory reporting, deciding on change approvals for loan and savings products, and reviewing audit logs. The FTC Safeguards Rule at 16 CFR 314.4 requires covered institutions to encrypt customer information, apply multi-factor authentication, adopt change management and log authorized user activity, and the penetration testing and vulnerability assessments it describes recur. Confirm with your regulator and auditor which obligations apply to your entity.