ClickHouse for financial services analytics

Why ClickHouse for financial services analytics needs a controlled build

A bank or fintech analytics lead is watching fraud signals and transaction volumes grow faster than the reporting layer can answer. Self-managed ClickHouse fits when the team needs to control where the data sits, who can query it and how it is recovered after a failure. The server is open source under the Apache License 2.0, so the institution can run it in its own cloud accounts, data centers or restricted networks without a managed-service dependency. ClickHouse Inc. also sells ClickHouse Cloud as a managed option, which is a separate decision with its own contract, hosting location and data terms.

Choosing a self-managed build moves work that a managed provider would otherwise carry onto the institution's own team or partner. The institution owns replication design (ReplicatedMergeTree tables coordinated by ClickHouse Keeper), backups with BACKUP and RESTORE, upgrade planning against the ClickHouse release lines, and the evidence auditors ask for, including access logs and change records. Each of these needs a named owner, a runbook and a test. Before committing, confirm which of these your current provider handles today, and price the staffing that replaces it. That comparison, not the license, usually drives the decision.

Treat the build as a set of controls from day one rather than a cluster to finish later. Restrict the default user, which starts with all permissions, and model access with roles, row policies and settings profiles. Decide early how users authenticate, whether through LDAP, Kerberos, X.509 certificates or JWT, because that choice shapes audit trails. Schedule restore tests on a spare cluster, since replication alone does not protect against human error or corruption. A pre-production environment with representative data and queries should prove these controls before any production fraud or risk workload moves in.

Which financial services requirements shape the ClickHouse build

This table maps the financial services requirements most likely to affect a self-managed ClickHouse build to the decisions they create for the platform team. The regulator, entity type and applicable regime determine which rows apply, so confirm scope with your compliance and legal owners before reading the rows as obligations. Use the table to see where ClickHouse configuration, documentation and evidence will be asked for.

Requirement	What it asks for	What it means for ClickHouse
DORA Article 28(3) and 28(8)	A register of all ICT contractual arrangements, and documented, tested exit strategies for services supporting critical or important functions	Record the ClickHouse deployment, its hosting provider and support arrangements in the register. Document and test how analytics data would be exported and moved to another platform.
DORA Article 30(2)	ICT contracts state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination	Where your ClickHouse storage, backups and Keeper nodes physically sit must match contract terms. Confirm data return terms cover exported tables and backup archives.
PCI DSS v4.0.1 scope	Defines the cardholder data environment by where cardholder data is stored, processed or transmitted, or what could affect its security	Tables holding primary account numbers or sensitive authentication data bring ClickHouse nodes, backups and Keeper hosts into scope. Keep card data out of fraud and risk datasets where tokenized or masked values will do.
PCI DSS requirement goals on access and logging	Restricted access to cardholder data and logging of access to it, assessed through the entity's ROC or SAQ	Use ClickHouse users, roles and row policies to limit who can query card-related columns. Confirm query logs capture access to those tables for assessors.
FTC Safeguards Rule, 16 CFR 314.4(c)(5)	Multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing	Direct ClickHouse logins and admin accounts need an MFA path, which usually means fronting access with an external identity provider. Any exception must be approved in writing.
SEC ICFR IT general control areas	Program development, program changes, computer operations and access to programs and data, relevant to SOX 404 assessments	Version upgrades, schema changes and access grants on ClickHouse are the change and access evidence auditors will ask to see. Keep change records and role assignments reviewable.
Swift CSCF v2026	Controls assessed independently for Swift users, with annual attestation in KYC-SA	If ClickHouse sits in the Swift-connected environment, its hosts, access and logging fall under the relevant controls. Confirm applicability with your Swift security officer.
Row policies and access control	Need-to-know access and separation of duties across analytics users	Use row policies, settings profiles and quotas, and restrict the default user, which starts with all permissions. Test that policies hold for each role.
Backups and restore testing	Recoverability of financial records and documented, tested recovery	ClickHouse documentation notes replication does not protect against human error or corruption, and warns that untested backups will probably not restore. Schedule restore tests on spare clusters and keep the results.

Choosing where the cluster runs for regulated data

For banks, payment institutions and other financial entities in scope of DORA, the first question is where the ClickHouse nodes, Keeper nodes, backup targets and support access actually sit. DORA Article 30(2) requires every ICT services contract to state where services are provided and data processed, with advance notice of changes, and to cover data return on insolvency or termination. A self-managed cluster in your own EU data center or in a cloud region you select keeps that location under your control, but the same obligations reach every hosting provider, colocation operator and backup vendor in the chain.

Contracted locations: Name each region, data center and country for production, replicas, backups and disaster recovery sites in the hosting contract.
Change notice: Require advance notice before any provider moves workloads, adds a subprocessor or changes where support staff access the environment.
Data return: Specify export formats and timelines for ClickHouse table data, backups and configuration if the provider fails or the contract ends.
Register entries: Record each hosting and support arrangement in the register of information required by DORA Article 28(3).
Exit plan: Document and test how the cluster would be restored at an alternative provider, consistent with DORA Article 28(8).

Confirm the hosting locations and contract clauses with your provider and with your national competent authority before go-live, and check how your own supervisor interprets them.

Configuration that matters for fraud, risk and transaction workloads

Fraud, risk and transaction analytics put firm demands on how ClickHouse stores, authenticates and shares data. The cards below cover the replication, identity, access and ingestion choices that a financial services team should settle before loading production transactions, and what each one needs to be checked against.

Replicated tables on dedicated Keeper hosts

Transaction history used for fraud scoring and regulatory reporting cannot depend on a single node. ReplicatedMergeTree tables coordinated by ClickHouse Keeper keep copies on several replicas, and the replication guide recommends at least three Keeper nodes on dedicated hosts with about 4 GB of RAM each. Check that Keeper runs apart from the data nodes and that a recovered replica resyncs from a healthy peer in your failure tests.

Named users and roles for analysts

Fraud analysts, model owners and risk teams should not share credentials or inherit broad rights. ClickHouse access control models users, roles, row policies, settings profiles and quotas, and the documentation recommends managing them through SQL. Map each role to a documented business function so that access reviews can compare grants against the approved access model.

Restricting the default user

A fresh ClickHouse installation starts with a default user that has all permissions. Left in place, it becomes a privileged account that bypasses the role model used for cardholder and account data. Disable or restrict the default user before any production data is loaded, then confirm that every administrative action is traced to a named person.

LDAP, Kerberos, X.509 and JWT sign-in

Banks usually centralize workforce identity, so analyst logins should come from the directory and not from local passwords. ClickHouse supports LDAP directories, Kerberos, SSL X.509 certificates, an HTTP authenticator and JWT as external authenticators. Choose one primary method for interactive users, use certificates for service accounts and pipelines, and confirm how deprovisioning removes access on the ClickHouse side.

Quotas and profiles for shared analytics

Risk model runs, ad hoc investigations and dashboards often share one cluster, and an unbounded query from one team can slow fraud scoring for everyone else. Settings profiles and quotas limit memory, execution time and query volume per role. Agree these limits with the fraud and risk owners, and test them against the heaviest realistic investigation before go-live.

Kafka and PostgreSQL ingestion paths

Card transactions often arrive through a streaming platform, while account and customer reference data sits in PostgreSQL. Each ingestion path needs a documented owner, replay behavior after failure and a check that row counts reconcile with the source system. Record which pipeline is the system of record for each table, because restoring from backup and replaying from the source produce different gaps.

How a financial services ClickHouse rollout runs in phases

The sequence moves from defining which data and systems fall into regulatory scope to a tested, documented production cluster that the institution can operate and upgrade on its own schedule. Each phase closes with evidence that the next one depends on.

Scope the regulated data and PCI boundary
Start by listing the datasets that will land in ClickHouse, such as transaction records, card-related fields, fraud signals and trading or risk data, and classify each one by sensitivity and regulatory relevance. Identify whether any cardholder data or sensitive authentication data would enter the cardholder data environment, since PCI DSS applies to systems that could affect that environment, not only those that store it. Your compliance and security leads sign off on the data inventory, the in-scope network segments and the data residency requirement. The output is a written scope document that defines what the cluster may and may not hold.
Build a pre-production environment with representative data
Stand up a non-production cluster in the infrastructure you control and load it with representative data and the queries your analysts and risk teams actually run. Use masked or synthetic data where production values would move the environment into a higher scope, and record which approach you chose. Confirm the target ClickHouse version against the current stable and LTS lines and the security policy before installation. The check that closes this phase is a set of benchmark and correctness results for your real query patterns, plus a changelog review noting any backward-incompatible changes that affect your schema or queries.
Build replication with ClickHouse Keeper
Design the replicated topology using ReplicatedMergeTree tables coordinated by ClickHouse Keeper. The replication guide recommends at least three Keeper nodes on dedicated hosts for production, so plan those hosts and their placement across failure domains as part of the infrastructure design. Test failure scenarios deliberately: stop a replica, confirm reads and writes behave as designed, then bring it back and verify it resynchronizes from a healthy replica. Replication handles hardware loss, but it does not protect against bad deletes or corrupted writes, which is why backups come next. The output is a documented failover test log with timings you measured.
Prove backup and restore on a spare cluster
Configure BACKUP and RESTORE for the in-scope databases and tables, targeting the storage your architecture team has approved, whether local disk, S3-compatible storage or Azure Blob Storage. Use full and incremental backups as your recovery objectives require. Then restore into a spare cluster and compare row counts, checksums and sample queries against the source. The ClickHouse documentation warns that a backup never test-restored will probably not restore properly, so this restore must be repeated on a schedule, not run once. The closing evidence is a signed restore report that your risk owner accepts.
Configure access and audit controls
Replace the default user's broad starting permissions, then define users, roles, row policies, settings profiles and quotas through SQL so every change is reproducible and reviewable. Connect authentication to your existing directory, using the external authenticators that fit your environment, such as LDAP, Kerberos, X.509 certificates or JWT. Map each role to a documented business function, and record who approved it. Confirm that query and access logs are retained and forwarded to the system your security team monitors. Auditors will look for evidence that access is granted, reviewed and removed, so the output is an access matrix, a tested joiner and leaver procedure, and a sample audit trail.
Go live with an upgrade and change policy
Before production traffic moves over, agree in writing who approves changes, how upgrades move through pre-production first, and which ClickHouse release lines you will run. The security policy lists currently supported versions, and the production guidance recommends stable releases for most production use, so set a rule for when you move between releases and how you will track end of support. Rehearse a rolling upgrade and a rollback in pre-production. The cutover is complete when the runbook, on-call ownership, monitoring thresholds and the exit strategy for the platform are documented and the first restore test is on the calendar. Duration depends on the scope you agree, so confirm the plan and timeline with your delivery lead before work starts.

How backups, restore tests and retention satisfy resilience expectations

Replication does not protect against human error or corruption. A ReplicatedMergeTree cluster keeps replicas in step, so a bad DROP TABLE, a faulty migration or a corrupted part is replicated just as faithfully as good data. For a bank or fintech, that means the resilience case for ClickHouse needs a separate recovery path. ClickHouse BACKUP and RESTORE cover full and incremental backups of tables, partitions or whole databases to local disk, S3-compatible storage or Azure Blob Storage. The destination is a design decision with consequences for DORA Article 30 and for where transaction-derived data is allowed to sit, so confirm it with your data residency and legal teams before the first backup job runs.

A backup that has never been restored should be treated as unproven. The ClickHouse backup documentation warns that an untested backup will probably not restore when it is needed. Build a scheduled restore test into the operating calendar: restore a recent backup to a spare cluster, check row counts and key aggregates against source-of-record figures for trading, risk and fraud tables, and record the elapsed time. The results feed the recovery objectives and exit plans that DORA Article 28(8) expects for ICT services supporting critical or important functions. Ask your partner or internal team to document who runs the test, what evidence is kept, and what happens when a restore fails.

Retention and audit trails are choices the institution must make and write down. Decide how long each dataset is kept in backups, how long it stays queryable, and which records must be retained for supervisory, tax or litigation purposes. Those periods also set the scope of any erasure request under GDPR and the size of your backup estate. Audit evidence of who changed access, ran restores or dropped data should be kept outside the cluster being audited, and access to backup buckets should be restricted separately from the ClickHouse users and roles that query the data. Confirm these periods with compliance counsel, not with the database team alone.

Compliance considerations to plan with your assessor

Financial services teams rarely need one certificate for an analytics platform. They need a set of evidence that shows where ClickHouse data lives, who can reach it, how it is recovered, and which regulator or payment brand asks for each piece. DeployOpen prepares the systems, configuration and evidence for these assessments, but independent auditors, Qualified Security Assessors and supervisors decide what is compliant.

DORA register and exit strategy

DORA Article 28(3) requires a register of information covering all contractual arrangements for ICT services, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. For a self-managed ClickHouse cluster, the register should name the platform, the hosting provider, any support partner and any managed object storage used for backups. Ask your assessor which functions count as critical or important, and plan a tested migration path for the data if you ever need to leave the platform.

DORA contract terms for data location

DORA Article 30(2) requires every ICT services contract to state where services are provided and data processed, to give advance notice of changes, and to cover data return on insolvency or termination. Support, hosting and backup contracts for your ClickHouse estate should match this. Confirm with legal whether the backup target, the Keeper nodes and any remote support access fall inside the stated locations, because the replica and backup footprint is often wider than the primary cluster.

PCI DSS scope and the ROC or SAQ route

PCI DSS applies to any system that stores, processes or transmits cardholder data or could affect the security of that environment. If ClickHouse holds card numbers, tokens tied to cardholder data, or logs that capture them, it is in scope and the payment brands decide which validation path applies. Assessments are documented either as a Report on Compliance by a Qualified Security Assessor or as a Self-Assessment Questionnaire, each with an Attestation of Compliance. Map the data flows with your assessor before choosing a design, and confirm which version your acquirer or brand requires.

SOX IT general controls evidence

For US public companies, the SEC's guidance on management's report on internal control names program development, program changes, computer operations and access to programs and data as typical IT general control areas. For ClickHouse, this means evidence of who approved schema and version changes, who holds administrative and database accounts, and how batch jobs and backups run and are checked. Agree with your auditor which reports, change tickets and access reviews they will sample, and export those from your own tooling rather than from memory.

FTC Safeguards MFA requirement

Non-bank financial institutions under FTC jurisdiction must use multi-factor authentication for any individual accessing any information system, unless the Qualified Individual approves an equivalent control in writing. ClickHouse supports LDAP, Kerberos, X.509 certificates, HTTP and JWT external authenticators, but the database itself does not supply a second factor for every login path. Decide which access paths (analyst clients, BI tools, service accounts, and administrators) need MFA through an upstream identity provider, and document any written exception for paths that cannot use it.

Swift CSCF attestation scope

If your institution uses Swift, the Customer Security Controls Framework applies to the connected environment, and users must have controls independently assessed and attest compliance annually in the KYC-SA application. ClickHouse usually sits outside the Swift connected environment, but fraud and reconciliation analytics that pull Swift message data can bring it into view. Confirm with your Swift officer and assessor whether the analytics platform is in scope, and keep a network and access diagram that shows where messages and derived data are copied.

NIS2 interaction with DORA

DORA is a sector-specific Union act for the purposes of NIS2 Article 4, so financial entities identified as essential or important under NIS2 need to map obligations across both. In practice, the incident reporting, supply chain and risk management records you build for DORA can often support NIS2 evidence, but the two frameworks have different scopes and timelines. Ask your counsel which regime applies to each entity in your group, and keep one control register that cross-references both.

What financial teams ask before running ClickHouse themselves

What does a self-managed ClickHouse analytics platform cost over time?

Total cost splits into one-time work and recurring running costs. One-time work covers architecture, sizing, the build, security configuration, backup and restore testing, and migration of existing data. Recurring costs cover the infrastructure you pay your cloud or data center provider for, storage growth, Keeper and replica capacity, monitoring, upgrades, and support staff or retainer time. The main cost drivers are data volume and retention period, query concurrency, the number of replicas and sites, and how many regulated data sources feed the cluster. Ask any quote to separate fixed-scope build fees from retainer fees, to list each infrastructure component you will pay for directly, and to state which costs change if retention or ingestion volume grows.

How long does a ClickHouse rollout take at a bank?

Duration depends less on ClickHouse itself than on the controls your organization must evidence before go-live. The main timeline drivers are the number and sensitivity of data sources, the approval path for the hosting location and data residency, identity integration with your directory, the pre-production testing window with representative data and queries, and how long your change board takes to approve production changes. Restore testing also takes time, because a backup that has not been restored on a spare cluster is not proven. Ask for a written scope with milestones, the dependencies you must clear, and the review gates where your risk or compliance functions sign off.

What must the bank provide before ClickHouse work starts?

The bank typically provides the hosting environment, network segments, identity sources, certificate authority access, and named owners for data, security and operations. Financial teams also need to supply sample data and representative queries for the pre-production environment, the data classification for each source, and the retention rules that apply to each dataset. Access to change management, vendor risk and procurement processes is needed early, because they set the pace of the engagement. Confirm in the quote who will provision the infrastructure, who holds administrative credentials, and what happens to access and configuration documentation at handover.

Can our internal team run ClickHouse after the build?

Yes, if the team has the skills and time to operate it, and a practical handover is planned from the start. Running a cluster involves replica health checks, ClickHouse Keeper monitoring, backup job verification, periodic restore tests, access reviews, and upgrade planning. Teams without a database operations background usually need a training period, runbooks for common incidents, and a clear escalation route. Ask what documentation, runbooks and walkthroughs are included in the build, which operational tasks stay with your team, and whether a retainer for support or upgrades is a better fit for your staffing.

How do DORA contract terms apply to ClickHouse support?

DORA applies to the financial entity, so the contract with any ICT service provider must meet its requirements. Article 30(2) requires every ICT services contract to state where services are provided and data processed, to give advance notice of changes to those locations, and to cover data return on insolvency or termination of the provider. Article 28(3) expects the service to appear in your register of information on contractual arrangements, and Article 28(8) expects documented, tested exit strategies for services that support critical or important functions. Ask a provider to reflect these terms in the contract, to name the locations where support access and data are handled, and to describe how the cluster can be exited or moved. ClickHouse itself is open-source software under the Apache License 2.0, so a source license does not create the contract terms you need. DeployOpen does not issue DORA attestations, and the Regulation does not provide a certification scheme for this work.

How do upgrades stay within supported ClickHouse versions?

Start by matching your running version to the current entry in the ClickHouse security policy. That policy lists versions 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and all other versions as unsupported. According to the ClickHouse production FAQ, stable releases ship roughly monthly, the three latest stable releases receive diagnostics and bug fix backports, and LTS releases ship twice a year and are supported for a year. Teams that need a longer support cycle usually pick an LTS line and plan an upgrade before its support window ends. Each upgrade should be rehearsed in a pre-production environment with representative data, the changelog should be read for backward-incompatible changes, and rollback steps should be tested. Ask any quote to include a named upgrade cadence, the target versions for the first year, and whether upgrades are covered by a retainer or billed per change.

Does a ClickHouse build help with PCI DSS scope?

A build can support scoping work, but it does not decide scope or certify compliance. PCI DSS applies to entities that store, process or transmit cardholder data or could affect the cardholder data environment, and the payment brands determine who must validate. Compliance is documented through a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance. If card data reaches ClickHouse, the cluster may fall inside scope, which affects network segmentation, access control, logging and key management. Ask your assessor early which datasets are in scope, and ask any provider to document how the cluster separates cardholder data from analytics data where possible.

How DeployOpen scopes and supports regulated ClickHouse work

DeployOpen starts every regulated ClickHouse engagement with a written, fixed scope that names the clusters, the data sources such as Kafka topics or PostgreSQL databases, the access model, the retention rules and the evidence the institution expects to hold at the end. Deliverables and timelines are agreed in writing before work begins, so the people who own the risk, compliance and operations can review what is in and out of scope. The quote follows from that scope. Ask any provider to show which DORA Article 30(2) items, PCI DSS requirements and backup restore tests are covered by named deliverables, and which are left to your team.

The build runs in your own cloud accounts, data centers or restricted networks, so cluster topology, Keeper placement, users.xml and role grants, row policies, TLS settings and the backup target stay under your control. DeployOpen can run security testing against the deployed cluster and its surrounding APIs, and prepare the configuration baselines, access reviews and restore-test records that your auditors or assessors will request. It does not issue attestations, Reports on Compliance or any certification, so confirm early which independent assessor will review the work and what they will need from the platform team.

Because a ClickHouse cluster used for fraud or transaction analytics changes with each stable release and each security update, many institutions keep an ongoing arrangement after go-live. DeployOpen offers retainers for ongoing support, upgrades and continuous testing, and these can be scoped to the supported release lines your team has approved. Ask any provider how upgrades are rehearsed on a pre-production cluster with representative data, how restore tests are recorded, and how the retainer maps to the exit strategy and contract clauses your DORA register requires.