Finecko Documentation

Appearance

FAQ – Security ​

How does Finecko protect data in transit? ​

All communication between your users, your integrations, and the Finecko platform is encrypted using TLS 1.2 or TLS 1.3. This applies to:

  • Browser and API traffic – every HTTPS request to your Fineract instance is encrypted end-to-end. Plain HTTP is not accepted.
  • Internal service traffic – communication between Finecko's infrastructure components (application nodes, databases, message brokers) is encrypted within the cluster network.
  • Backups in transit – backup data is encrypted before transmission to remote storage.

TLS certificates are managed and renewed automatically. There is no manual certificate rotation step required from your side.

How is data encrypted at rest? ​

Data stored on Finecko infrastructure is encrypted at rest using AES-256:

  • Database volumes – the underlying block storage used for tenant databases is encrypted at the volume level by the cloud provider (Oracle Cloud Infrastructure). This covers all data, logs, and temporary files.
  • Backup files – automated database backups are encrypted before being written to object storage. Encryption keys are managed separately from the backup data itself.
  • Secrets – API keys, database credentials, and other secrets are stored in Kubernetes Secrets and are not exposed in application configuration files or container images.

How does Finecko control who can access what? ​

Access control in Finecko operates at two levels:

Application-level (Apache Fineract RBAC):

Apache Fineract has a granular role-based access control system built in. Every API endpoint, every screen in the web UI, and every data operation is controlled by a specific permission. Roles are collections of permissions, and users are assigned one or more roles. This allows you to model your institutional hierarchy precisely:

  • A loan officer can create and disburse loans but cannot approve them
  • A branch manager can approve loans up to a configured limit
  • A reporting analyst can read all loan data but cannot create or modify any records
  • An integration user can access specific API endpoints and nothing else

Permissions are enforced server-side. They cannot be bypassed by crafting API requests directly.

Infrastructure-level:

Access to Finecko's underlying infrastructure (servers, databases, Kubernetes cluster) is restricted to Finecko engineers via role-based cloud IAM policies. No customer data is accessible to Finecko staff except under a support request with explicit customer consent. Database access from the internet is not permitted — databases are on private cluster networks only.

Does Finecko keep audit logs? ​

Yes. Apache Fineract maintains a full audit trail of all application-level actions:

  • Every API call that modifies data is logged with the user, timestamp, action type, and affected entity
  • The audit log is accessible via the Fineract API (GET /fineract-provider/api/v1/audits) and through the web interface
  • Audit entries cannot be deleted or modified by application users — they are append-only records

This gives you a complete record of who disbursed a loan, who approved an application, who changed a configuration setting, and when each action occurred — which is typically required for regulatory reporting and internal compliance.

Is my data isolated from other Finecko customers? ​

Yes. Every Finecko customer runs in a completely isolated tenant database. This is a fundamental architectural property of Apache Fineract's multi-tenancy model:

  • Each customer has their own database instance, not just a schema or a filtered view
  • Application queries always include the tenant identifier in the connection routing — there is no query path that can reach another tenant's data
  • Tenant databases are not shared with any other customer under any circumstances

This applies to all data: loans, clients, savings accounts, transactions, configuration, and audit logs.

See Multi-Tenancy for the full architectural explanation.

How does Finecko handle data backups? ​

Automated backups run daily for every tenant database:

  • Frequency: Daily automated snapshots, with the ability to request point-in-time recovery for critical incidents
  • Retention: Backups are retained for a minimum of 30 days
  • Encryption: All backup files are encrypted at rest (AES-256) before being written to remote object storage
  • Geographic separation: Backup storage is in a different physical location from the primary database, so a failure of the primary data centre does not affect backup availability
  • Restoration testing: Backup restoration is tested on a regular cadence to confirm recoverability before an incident occurs

What is Finecko's disaster recovery plan? ​

In the event of a platform-level failure:

  • Recovery Time Objective (RTO): Services can be restored within hours for data centre-level failures, depending on the severity of the incident
  • Recovery Point Objective (RPO): Maximum data loss exposure is the time since the last successful backup (up to 24 hours for a catastrophic database failure, significantly less for partial failures where the primary database remains intact)
  • Redundancy: Application nodes run on Kubernetes with multiple replicas. If a node fails, traffic is automatically rerouted to healthy nodes with no manual intervention required
  • Runbooks: Finecko maintains documented recovery runbooks for common failure scenarios (database node failure, storage failure, regional outage), updated whenever the infrastructure changes

How does Finecko handle security patches and vulnerabilities? ​

Finecko tracks security advisories for all platform components:

  • Apache Fineract – Finecko monitors the official Apache Fineract security advisory list. Critical patches are applied to managed instances within a defined SLA after the upstream release is verified
  • Infrastructure dependencies – base container images, database engines, and Kubernetes node OS packages are updated on a regular patching cycle
  • CVE monitoring – container images are scanned for known vulnerabilities as part of the CI/CD pipeline. Images with critical CVEs are not deployed to production

If a security vulnerability requires emergency patching outside the normal cycle, Finecko will apply the patch and notify affected customers.

Can I control where my data is stored (data residency)? ​

Data residency options depend on your plan. Contact [email protected] to discuss requirements for specific regions or jurisdictions. For regulated financial institutions with explicit data localisation requirements, Finecko can discuss dedicated deployment options.