Event streaming for financial services

Why event streaming for financial services is a controls problem first

For most banks and fintechs that need payments, trades and account events ordered, protected and retained for audit, self-hosted Apache Kafka is the primary fit. It has the widest client ecosystem, a documented security model (TLS, SASL, and ACLs enforced by the StandardAuthorizer in KRaft clusters) and Kafka Connect for moving data into ledgers, fraud engines and archives. Alternatives such as NATS or RabbitMQ can suit narrower messaging needs, but the controls evidence and replication tooling are where Kafka usually leads for regulated event backbones. Before choosing, confirm the current supported releases on the Apache Kafka downloads page and plan your upgrade path to a KRaft-only version, since ZooKeeper mode was removed in Kafka 4.0.

What changes in financial services is less the technology than what the auditor will ask to see. Ordering and exactly-once expectations must be defined per flow: a payment instruction may tolerate at-least-once delivery only if consumers are idempotent and the business key is recorded. Access control and encryption must be shown as configuration, not intent: which principals can produce to or consume from each topic, whether every listener requires TLS, and whether allow.everyone.if.no.acl.found is disabled. Retention is a separate decision, because topic retention for replay is not the same as the audit record your regulator expects. Cross-site replication, typically with MirrorMaker 2, also has to replicate ACLs and offsets and be tested, not assumed. Scope is set by PCI DSS (if card data flows through topics, the cluster may fall inside the cardholder data environment) and by DORA's requirements on ICT third-party arrangements, exit strategies and tested resilience.

DeployOpen plans, builds, hardens and documents these controls in your own data centers or cloud accounts, and prepares the configuration, access records and test results that assessors sample. It does not issue audit reports, attestations or certifications; your independent auditor, Qualified Security Assessor or competent authority makes those determinations. Before scoping work, confirm with your compliance lead which regulations apply to each flow, which topics carry personal or cardholder data, and which recovery objectives the business has set for each function.

Which regulatory requirements shape the streaming build

This table maps each regulation or control framework that commonly applies to a financial streaming platform to what it asks for and what it changes in the build. Read it as a checklist of design decisions to settle before the cluster is sized, and confirm applicability with your compliance and legal teams.

Requirement	What it means for the build	Evidence to prepare
DORA Article 28(3): register of ICT contractual arrangements	Every ICT service supporting the streaming platform, including self-hosting support contracts and cloud infrastructure, needs an entry in the register of information.	Register entries mapped to each service, provider, location and the functions the streams support
DORA Article 28(8): exit strategies for critical or important functions	If topics support a critical function, the exit plan must cover moving topics, schemas, consumer offsets and connector configuration to another platform.	Documented, tested exit and transition plan with data export and replay steps
DORA Article 30(2): contract terms on data location and data return	Contracts must state where data is processed and stored, give advance notice of changes, and cover return of data on termination or insolvency. Cluster placement and backup locations follow from this.	Contract clauses naming hosting regions, sub-processors and data return procedures
DORA Article 26(7) and TIBER-EU alignment	DORA provides no certification scheme. The only authority-issued attestation it names is that a threat-led penetration test met requirements. Streaming brokers, connectors and admin interfaces are typical test scope.	Scoped TLPT plan, test results and remediation evidence; confirm with your competent authority which entities must test
PCI DSS v4.0.1: cluster placement in or out of the cardholder data environment	If card data appears in topics, the brokers, Connect workers, schema registry and monitoring that touch it are in scope. Keeping cardholder data out of payloads and tokenizing it can narrow scope. Segmentation must be tested.	Network diagrams, data flow diagrams, segmentation test results and ACL and TLS configuration records
Swift CSCF v2026 controls for Swift-connected institutions	Where streams feed or carry Swift message data, the controls on system hardening, access control and logging apply to the platform. Swift controls are assessed independently and attested annually in KYC-SA.	Control mapping for the 32 controls, independent assessment report and KYC-SA attestation
SEC Release 33-8810: IT general controls for SOX 404	Program development, program changes, computer operations and access to programs and data are the areas assessors examine. For streams feeding financial reporting, change control on topics, connectors and ACLs becomes part of ICFR evidence.	Change tickets, access reviews for ACLs and admins, job and connector run logs, and ownership records
FTC Safeguards Rule, 16 CFR 314.4(c)(5): MFA for non-bank institutions	Anyone accessing the streaming admin consoles, Connect REST API or broker management tools needs multi-factor authentication unless the Qualified Individual approves an equivalent control in writing. SASL with OAUTHBEARER or SCRAM handles client authentication, not administrator access.	Written MFA policy for administrative access, approved exceptions and identity provider configuration

What data flows through the streams and which systems produce it

Most of the traffic on a financial services streaming platform falls into four event families, and each one shapes topic design differently. Payment instructions and payment status events move between channels, payment hubs and clearing connections. Trade lifecycle events (order, execution, allocation, settlement) come from order management and trading systems. Account balance and ledger change events originate in core banking, and fraud and sanctions screening signals come from risk engines and screening services that consume the same payment stream. Before any topic is created, the architecture team should write down, per family, which system is the producer, which consumers are allowed to read it, and how long each consumer needs the history. Those answers decide how many topics exist and whether a single topic can mix event types safely.

The sensitive fields determine how much of that traffic can be sent in clear text. Primary account numbers (PANs), account identifiers and personal data in payment messages are the fields that drive design choices. The usual options are to tokenize the PAN before it enters the stream, to encrypt specific fields at the producer with keys held outside the broker, or to keep the sensitive value in the source system and publish only a reference. Each option has a cost: tokenization adds a lookup service that must itself be highly available, and field-level encryption makes schema evolution and downstream search harder. Confirm with your data protection and payments teams which fields are regulated before a schema is published, because a schema change later will reach every consumer and every retained log segment.

Cardholder data in a topic brings the cluster into the cardholder data environment, which is the main scope decision for this use case. Under PCI DSS, any system that stores, processes or transmits cardholder data, or that could affect the security of that environment, is in scope, so a broker that retains a PAN in its log is in scope even if no one queries it. Engineers should confirm with the QSA or internal assessor whether a tokenized or truncated PAN still counts as cardholder data for their design, and document that decision with the data flow diagram. Core banking, card processing and payment hubs are usually the producers of these fields, while risk engines and data warehouses are the most common consumers. Keeping card fields out of the streams that feed analytics is often the simplest way to keep the analytics platform out of scope.

Deployment constraints for banks versus fintechs

A bank with an on-premises or private cloud estate usually runs the streaming cluster in its own data centers, because core banking, payments hubs and fraud systems already sit there. The design question is less where the brokers can run and more how they reach the sites that hold the payment and account data. Two data centers, or a primary site with a recovery site, are the common starting point, and the replication design has to match the recovery objectives agreed for each function.

Cluster location: Brokers, Kafka Connect and their supporting hosts can run on the bank's own hypervisors or private cloud, with no dependency on a public managed service.
Cross-site replication: MirrorMaker 2 replicates topics, consumer groups with offsets and ACLs between clusters, so the second site can be kept current, but failover still needs tested procedures.
Data location commitments: Where the cluster is hosted must match the contractual terms the bank holds with its own infrastructure and any outsourced hosting provider.
PCI DSS scope: A bank that issues cards or processes card payments must decide whether the cluster is inside the cardholder data environment, based on whether it stores, processes or transmits cardholder data or could affect its security.
Operating model: Kafka 4.x requires KRaft mode and Java 17 for brokers and Kafka Connect, so older ZooKeeper-based clusters need a planned migration.

Confirm with the bank's architecture and risk teams which data centers and recovery sites are in scope, and who signs off the PCI scope boundary before the first topic is created.

Which open-source platforms fit financial event streaming and why

Payments, trades and account events in a bank or fintech need a backbone that orders events, encrypts and restricts access, keeps an audit trail and survives a site failure. The cards below cover the core streaming platform, its connector and dataflow tools, the batch orchestrators that run around streams, and the alternatives and licensing limits to check before you commit.

Apache Kafka as the core backbone

Apache Kafka is licensed under Apache-2.0 and has no paid edition from the project itself, so the license cost is zero and the cost sits in your own operations and support. From 4.0 it runs only in KRaft mode, so ZooKeeper-based clusters must migrate first. Supported releases are 4.3.1, 4.2.2 and 4.1.2. Confirm that clients authenticate with SSL/TLS plus SASL (SCRAM or OAUTHBEARER are common choices), that the StandardAuthorizer ACLs are set without relying on an open default, and that MirrorMaker 2 covers the replication you need for resilience.

Kafka Connect for system integration

Kafka Connect moves data between Kafka and core banking, card processing, ledgers and data warehouses through source and sink connectors. It runs in standalone or distributed mode and is administered through a REST API. It has no graphical interface, so connector configuration is done through the API or third-party tools, and your team should agree on how those configurations are versioned, reviewed and audited. Connector quality varies, so check each connector's license, supported versions and offset behavior before it touches payment data.

Apache NiFi for governed dataflows

Apache NiFi is an Apache-2.0 dataflow system with a browser-based UI for designing, controlling and monitoring flows. Its data provenance feature records lineage from beginning to end, which helps when an examiner or internal audit asks where a specific transaction record came from and where it went. It suits teams that prefer visual flow design over writing connector configurations by hand. Check the cluster's TLS, user authentication and policy settings, and confirm how provenance data is retained and protected, since it can contain sensitive payload details.

Apache Airflow and Dagster around streams

Apache Airflow 3.3.2 (Apache-2.0) and Dagster 1.13.26 (Apache-2.0) orchestrate the batch work that surrounds a stream: reconciliation between the event log and ledgers, daily regulatory extracts, and reprocessing jobs after an incident. Neither replaces the streaming platform for low-latency delivery. Use them for scheduled and dependency-driven tasks, and keep their credentials, DAG code and run logs inside your controlled environment. Confirm how each handles secrets and whether your team has the skills to operate it alongside the broker.

Pulsar, NATS and RabbitMQ as alternatives

Apache Pulsar, NATS and RabbitMQ can fit when the requirement differs from a Kafka log. RabbitMQ suits task queues and AMQP-based messaging between services. NATS suits lightweight, low-latency request and messaging patterns. Pulsar offers its own geo-replication and multi-tenancy model. Each changes how ordering, replay, retention and ACLs behave, so confirm those against your payment and audit requirements before choosing. Ask whether your operations team already runs one of these, because an unfamiliar broker adds on-call and recovery risk.

Licensing limits to check first

Several tools in adjacent categories carry restrictions. Dify's modified Apache License 2.0 requires a commercial license to operate a multi-tenant service from the source code. The Airbyte platform repository uses the Elastic License 2.0. Camunda 8 source code under the Camunda License 1.0 permits use only in non-production environments without a commercial license. Review each license with your legal team before a pilot moves into production, and do not assume that an open-source label covers every component in a bundle.

Integration points and deployment patterns that keep evidence intact

Each card below is a deployment decision that either produces evidence an assessor can sample or leaves a gap they will question. Authentication, authorization, retention, replication, integration and scope separation together determine what a bank or fintech can show under DORA, PCI DSS and internal audit. Agree the evidence each control must produce before the first topic is created.

TLS and SASL client authentication

Kafka authenticates clients, brokers and tools with SSL or SASL, and the documented SASL mechanisms include SCRAM-SHA-256, SCRAM-SHA-512 and OAUTHBEARER. Security is optional in Kafka, so clusters can run with unsecured or mixed listeners unless you disable them. Confirm that no plaintext listener is reachable from production networks. Tie OAUTHBEARER or SCRAM credential lifecycle to the identity platform so that joiners and leavers are reflected in broker access. The evidence is the listener configuration, the authentication settings and the account population an assessor can compare against HR records.

ACLs per topic and consumer group

In KRaft clusters, the StandardAuthorizer stores ACLs in the cluster metadata log. Resources without ACLs are restricted to super users unless allow.everyone.if.no.acl.found is set to true, so keep that key at false and grant access explicitly. Model ACLs per topic for producers and per consumer group for readers, and keep super user membership to a short, named list. The evidence is the exported ACL set, which maps each payment or trade topic to the service accounts allowed to write or read it.

Retention and archive tiering for audit

Retention in Kafka is a topic setting, so the audit window for payment and account events must be set per topic and documented against the period your regulators and internal policy require. Topics hold recent events for consumers, while a separate archive stores the immutable history that auditors will request. Confirm with your compliance team which retention period applies to each event class before configuration. The evidence is the topic configuration export, the archive manifest and a tested restore that reproduces a sample of events with their original offsets.

MirrorMaker 2 replication for resilience

MirrorMaker 2 is built on Kafka Connect and replicates topics with their configuration, consumer groups with offsets and ACLs between clusters. Replicating ACLs means access rules survive a failover, which auditors often ask about. Plan the replication topology and the failover runbook before go-live, and test switchover on a schedule. The evidence is the replication configuration, lag and checkpoint metrics, and dated failover test records showing which consumer groups resumed and what data was reconciled.

Kafka Connect for ledger and warehouse integration

Kafka Connect streams data between Kafka and other systems through source and sink connectors, running in standalone or distributed mode and managed through a REST API. Connect manages connector offsets automatically, which reduces the chance of silent duplicate or lost records when loading a ledger or warehouse. Connector configuration has no graphical interface, so store connector definitions in version control and restrict who can change them. The evidence is the versioned connector configuration, the change approval trail and offset records that show each sink received every event exactly once from the perspective of the target.

Separating PCI-scoped clusters and topics

PCI DSS applies to entities that store, process or transmit cardholder data or could affect the security of the cardholder data environment. Decide whether card-data topics live in a dedicated cluster inside the cardholder data environment or in shared clusters with strictly separated topics, and document the scoping decision with its rationale. Any shared cluster that carries card data brings its brokers, Connect workers and administrators into scope. The evidence is the scoping statement, network segmentation records, separate credentials and ACL exports that an assessor can sample against the cardholder data environment boundary.

How a financial services streaming rollout proceeds

The sequence moves from regulatory scope to a tested, evidenced platform, so each phase closes with a document or test result that a risk owner, auditor or supervisor can review. Nothing goes live until the controls it depends on have been built and checked.

Define scope and map regulatory obligations
DeployOpen works with the entity's compliance, risk and architecture owners to list which payment, trade and account flows will use the platform, and which of them support critical or important functions. The output is a scope statement with a DORA register of information entries for the ICT services involved, a documented decision on whether the cluster sits inside or outside the cardholder data environment, and a determination of whether Swift Customer Security Controls Framework scope applies. The step closes when the risk owner signs off the scope and the mapping.
Produce the reference design and threat model
The team documents topic and partition layout, producer and consumer groups, network zones, data classification of event payloads, and the trust boundaries between brokers, Kafka Connect workers, schema services and applications. A threat model records the abuse cases that matter for payments and trades, such as forged or replayed events, unauthorized consumers reading account data, and tampering with retention settings. The output is a reviewed design document and a threat register with owners for each accepted risk.
Build the platform on a supported Kafka release
DeployOpen installs Apache Kafka on a release listed as supported on the Kafka downloads page at the time of build, running in KRaft mode with no ZooKeeper, on Java 17 for brokers and Kafka Connect. Clusters are deployed in the entity's own data centers or cloud accounts, with infrastructure as code and a documented version baseline. The step closes with a build record that lists exact versions, configuration files and hardening settings, and with a confirmed upgrade path to the next supported release, checked against the Kafka upgrade notes.
Apply the security baseline
The baseline enables TLS for every client, broker and tool listener, removes any plaintext listeners, and configures SASL with a mechanism chosen by the entity, such as SCRAM or OAUTHBEARER, integrated with its identity provider. ACLs are defined per topic, consumer group and service identity, and allow.everyone.if.no.acl.found is left at its restrictive default unless a documented exception exists. Secrets for keystores, credentials and Connect configurations are held in a vault rather than in files. The output is a control-by-control configuration review, with test evidence showing that unauthenticated and unauthorized access attempts fail.
Test integration, ordering and delivery guarantees
Each payment, trade and account event flow is tested end to end with producers and consumers that represent the real services. The tests check per-key ordering under partition changes, idempotent producer behavior, consumer offset handling, and whether exactly-once semantics hold for the specific pipeline, including any Kafka Connect sinks that write to downstream databases. Duplicate and out-of-order scenarios are injected deliberately. The step closes with a test report that states, for each flow, which delivery guarantee the business owner has accepted and where downstream idempotency is still required.
Test replication, failover and recovery
Cross-site replication is configured, typically with MirrorMaker 2 for Kafka, which replicates topics, consumer group offsets and ACLs between clusters. The team runs planned switchover and failover exercises against recovery objectives agreed for each function, then measures data loss, lag and consumer recovery time. Topic backup and restoration are tested as separate scenarios. Results are recorded with dates, versions, configuration and the people who approved them. The step closes when the recorded results show whether each objective was met or what remediation is scheduled.
Assemble the evidence pack and hand over
DeployOpen compiles the evidence that compliance and audit teams will sample: the scope and register entries, the design and threat model, build records, ACL and TLS configuration exports, access review procedures, retention settings tied to audit requirements, test reports and failover records, and the runbooks for on-call staff. Operations staff are trained on the runbooks and the entity takes ownership of accounts, keys and monitoring. The output is a handover package and a list of controls with the evidence location for each. Independent auditors and assessors decide whether that evidence is sufficient.

Evidence assessors and supervisors ask for, and what produces it

This table maps each piece of evidence that assessors, supervisors and auditors typically request for a streaming platform carrying payments, trades or account events to the component or record that produces it. Read it as a checklist to agree with your assessor before the platform goes live, since the exact sample and format will depend on your scope. DeployOpen prepares the evidence and runbooks, while independent assessors issue any report or attestation.

Evidence item	What it shows	Producing component	Where it usually fails
ACL configuration exports	Which principals may produce, consume or administer each topic and group	Kafka StandardAuthorizer ACLs in the KRaft metadata log, exported on a schedule	Wildcard grants left in place, and resources with no ACL that fall back to super users
TLS configuration and certificate inventory	Which listeners require encryption, which protocols and certificates are in use, and when they expire	Broker and client listener configuration, plus a certificate register kept by the platform team	Plaintext listeners left enabled for internal tools or Connect workers
Authentication settings	Which SASL mechanisms and identity sources authenticate clients, brokers and tools	Broker SASL configuration, OAUTHBEARER or Kerberos integration settings, and the identity provider's records	Shared service accounts with long-lived passwords and no owner
Change records for program and configuration changes	Who changed broker, Connect and topic configuration, when, and under which approval	Change tickets linked to configuration-as-code commits and deployment logs	Manual changes made through the API or CLI with no ticket reference
Retention and archive records	Topic retention settings, archive destinations and whether records were kept for the required period	Topic configuration exports, archive job logs and object storage retention policies	Retention set by default, or archives that cannot be restored and read
Replication and failover test results	Whether replicated topics, consumer groups and ACLs recovered within the objectives set for each function	Test reports from MirrorMaker 2 failover exercises and offset translation checks	Tests run once at go-live and not repeated after upgrades or topology changes
Contract register and exit plan inputs	Which providers support the platform, where data is processed, and how data would be returned or moved	Contract register maintained by the organization, plus documented exit steps for the streaming components	Support vendors or hosting locations missing from the register
MFA evidence for administrative access	That every person with administrative access to brokers, Connect REST endpoints or hosts used a second factor	Identity provider logs, bastion or jump host logs and privileged access records	Break-glass accounts or API tokens that bypass the second factor
PCI DSS evidence an assessor samples	Scope of the cardholder data environment, network segmentation and access reviews for topics that carry card data	Network diagrams, scope documentation, access review records and log samples from the platform	Topics carrying card data that were not included in the scope definition

What buyers ask before hiring a partner for financial event streaming

What drives the cost of a financial event streaming engagement?

Scope, PCI placement, number of sites, connectors and retention drive most of the cost. A single-site cluster that carries no cardholder data is a very different job from a multi-site platform that feeds payment, fraud and ledger systems. Each added site adds replication design, testing and monitoring work. Each source or sink system adds connector configuration, schema agreements and testing. Retention multiplies storage and backup work. Ask the partner for a written scope that lists sites, connectors, topics by data class, retention periods per topic, and the compliance evidence to be produced, then price each of those items separately so you can see what moves the total.

What is one-time and what recurs in a self-hosted streaming platform?

The build is one-time work: architecture, deployment, security hardening, connector setup, replication, backup design and initial evidence. Recurring costs include the infrastructure you run (brokers, storage, network and backup capacity in your own accounts or data centers), patching and upgrades, monitoring and on-call, and any retainer for ongoing support or continuous testing. Ask the partner to separate fixed-scope delivery fees from retainer terms, and to state who pays the cloud or data center bills. Kafka itself is Apache-2.0 licensed with no paid edition from the project, so license fees for the broker are not the main recurring line.

How long does a financial event streaming implementation take?

The timeline depends on the agreed scope and on how quickly your teams can make decisions, not on a fixed duration. The main variables are the number of sites, the count of producing and consuming systems to integrate, the state of existing ACL and certificate processes, whether the cluster must sit inside the cardholder data environment, and how many approval gates your change process requires. Ask the partner to show a milestone plan with dependencies, the points where your risk, security and compliance teams must sign off, and which items are on the critical path. Treat any duration given before scope is written as an estimate to challenge.

What must our bank's own team provide during the engagement?

Your team supplies the decisions and access that the partner cannot make for you. Typically this means named owners for each producing and consuming system, data classification for every topic, the target network and identity setup, certificate authority or key management arrangements, change approval contacts, and the business owners who accept recovery objectives per function. You also need to confirm where the cluster may run, which accounts or data centers are approved, and who holds administrative credentials after handover. Ask the partner to produce a written responsibilities matrix before work starts so gaps surface early.

Can our team run a self-hosted Kafka platform after the engagement?

Yes, if your team has the operating skills and the handover is planned. Operating a broker cluster needs people who understand KRaft mode, Java runtime maintenance, TLS and SASL configuration, ACL management, partition and storage capacity, consumer lag, and replication health. Kafka 4.0 supports only KRaft mode, so older ZooKeeper-based designs need migration first. Ask the partner what runbooks, monitoring dashboards, alert thresholds and training are delivered, whether failover is exercised with your staff, and whether a retainer is available if you want continued support after handover. Confirm this with your own skills assessment rather than assuming it.

How are DORA and PCI DSS evidence packs prepared for streaming?

The partner prepares the systems, controls and evidence that your assessors will sample. For PCI DSS, that includes the cluster's scope decision, network segmentation records, TLS configuration, ACL definitions, log retention settings and access reviews. For DORA, it includes the register of information entries for the platform, contractual terms on data location and exit, documented and tested exit and transition plans, and recorded results of backup restoration and switchover tests. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so ask the partner which evidence will be produced, in what format, and how it maps to your assessor's request list.

How are Kafka upgrades handled without disrupting payment flows?

Upgrades move the cluster to a supported release through a planned, tested rolling process. The Kafka downloads page lists 4.3.1, 4.2.2 and 4.1.2 as supported releases, and the time-based release plan supports rolling upgrades from each release in the past year to the latest version. Before upgrading, the partner should confirm the Java version (Java 17 for brokers and Kafka Connect since Kafka 4.0), check Kafka Connect and client compatibility, and rehearse the change in a non-production environment. Ask for the upgrade runbook, rollback criteria, the test evidence kept for audit, and who approves each change window.

Questions to put to an implementation partner before signing

Ask how the partner will map DORA obligations into the build before any broker is installed. Article 28(3) requires a register of information covering every contractual arrangement for ICT services, and Article 28(8) requires documented, tested exit strategies for services that support critical or important functions. Ask who maintains the register entry for the streaming platform, where the partner's own support and build tooling sit in that register, and how the exit plan would move topics, schemas, consumer offsets and ACLs to another operator. Under Article 30(2), every ICT services contract must state where services are provided and data processed, give advance notice of changes, and cover data return on insolvency or termination. Ask the partner to show you a contract clause draft that does all three, and to name the regions where backups and MirrorMaker 2 replicas will live. Also ask how they decide PCI DSS scope for the cluster: whether brokers that never see primary account numbers are kept outside the cardholder data environment, what evidence would support that position, and who signs off the scope decision with your QSA.

Ask how the partner tests ordering and exactly-once behavior, and what they will not promise. Kafka's idempotent producers and transactions are configuration choices that must be tested against your own payment flows, including consumer retries, rebalances and producer restarts during a settlement batch. Ask for the test plan, the topic and partition keys used for account and trade events, and the reconciliation job that proves no payment was lost or duplicated. Ask them to prove failover on a schedule, not once. The test should cover a failed site, an offset translation check for MirrorMaker 2 and a documented recovery time measured against the objective you set per function. On upgrades, ask which supported release they will start from and whether their path follows the Kafka rolling upgrade guidance, which supports upgrades from the last three releases to the latest version. Ask how ZooKeeper-based clusters, if any, are migrated to KRaft first. Finally, ask for the secure defaults they ship: SSL/TLS on every listener, which SASL mechanism is used, whether allow.everyone.if.no.acl.found is left false, who holds super user rights and how that access is logged. Confirm in writing who holds privileged access to brokers, Connect workers and the key store, and whether the written scope includes evidence packs, runbooks and a handover that your own team can run without the partner.

How DeployOpen scopes, builds and supports financial event streaming

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source streaming platforms inside the client's own data centers or cloud accounts. For financial event streaming, we start from a written scope that ties payment, trade and account flows to ordering, access, retention and resilience requirements before any cluster is built.

How we scope

Map which payment, trade and account event flows are in scope and which systems produce and consume them
Agree ordering, delivery and retention expectations per flow, including what audit and dispute processes need to replay
Record where the cluster sits relative to any cardholder data environment and which ICT services it supports

How we build

Deploy Apache Kafka in KRaft mode with TLS on client and broker listeners, SASL authentication and explicit ACLs
Configure MirrorMaker 2 replication and Kafka Connect integrations, with connector configuration kept under version control
Test topic recovery, failover and ACL behavior in a non-production environment before cutover

How we hand over

Deliver architecture, configuration, access model and runbooks for operators, including the upgrade and restore procedures
Provide evidence packs for the controls that auditors and assessors typically sample, prepared for the client's assessor to review
Train platform and security teams to run topic provisioning, ACL changes and failover exercises without DeployOpen

How we support

Offer ongoing support, upgrades and continuous testing as a retainer agreed in writing
Plan Kafka version upgrades against the supported release lines and the client's change calendar
Repeat switchover and restore tests on a schedule the client's continuity program requires