Best Kafka management tools for asset and wealth managers

Tools compared

Rank	Tool	Total (out of 100)	Out of the data path	Production access on request	Audit trail per person	Who can see unmasked data	Directory and Kafka sign-in	Many teams, shared clusters	Cost a year (modelled)
1	Kpow	87	One container, state in your Kafka, not a proxy	Time-boxed temporary policies via API, staged approvals, masking per resource	Every action with the IdP user, data queries included	Server-side masking, bypass guarded, no per-role exemption	SAML, OIDC, LDAP; Kerberos, SCRAM or mTLS to brokers	Tenants and per-action RBAC	$20,880
2	Kafbat UI	64	One stateless container	Per-resource RBAC, no approvals, masking for all viewers	Optional, reads at level ALL, no view	Same masking for every viewer	OAuth2, OIDC, LDAP; no SAML	Per-resource roles per cluster	$11,520
3	AKHQ	56	One stateless container	Regex groups, UI-only if JWT secret unset	Opt-in, no reads, no view	Global masking, same for every viewer	LDAP, OIDC; no SAML	Groups by resource and cluster pattern	$16,320
4	Lenses	53	HQ on PostgreSQL, agent and database per cluster	Strict global masking, no approvals	In-product audit log from Team tier	Strictest masking, admins included, no exemptions	SSO incl. Entra ID and Okta	Roles on groups only	$2,880 plus quoted licence
5	Confluent Control Center	35	Dedicated host, broker reporter JAR	Confluent RBAC, no DENY, no approvals	Broker principal, not always the person	No masking described	OIDC on self-managed	Admin access only, per TD	$2,880 plus quoted subscription
6	Conduktor	58	Console on PostgreSQL; Gateway proxy in the data path	Per-viewer masking, cross-team access requests	70+ event types with user, in the UI	Exemptions per user or group in Console	LDAP, OIDC	Per user or group, most permissive grant wins	$62,880; $152,880 with Gateway Core and Protect

No tool meets every column, and asset and wealth managers commonly pair a management tool for people with broker ACLs or an authorizer for services, and with encryption or masking on the write path for any field no reader needs in plaintext.

The tools, ranked for asset and wealth managers

What asset and wealth managers need from a Kafka management tool

This page is about asset management, wealth management and superannuation: fund managers, private banks and wealth managers, superannuation trustees, and the wealth technology platforms that serve financial advisers. Wealth managers that are also banks share most of a bank’s needs, covered in best Kafka management tools for banks, and the regulation-by-regulation view across banks, payments and insurance is in best Kafka governance tools for financial services. What sets this reader apart from a bank is the data and the size of the team: Kafka topics carry client identities, account numbers, holdings and member records, and the platform team that runs Kafka is usually much smaller than a bank’s, so the tool has to govern access well without becoming one more system to staff.

The Kafka these firms run tends to be small in volume and high in consequence. The fullest public account from inside a large asset manager is InfoQ’s write-up of a Goldman Sachs talk on its Core Front Office Platform, which describes a cluster in the firm’s Investment Management Division carrying about 1.5 TB a week, millions of messages and not billions, and designed so that no data is lost even when a data centre fails. The same account lists what the team built around the cluster: a REST service to see into it, a metrics capture component, and a sink that keeps a tabular copy of every message in a database for troubleshooting. That copy is a second store of transaction data with its own access list, and it exists so that engineers can look at messages without reading the topics directly, which is the job a management tool does in place. How Goldman Sachs uses Apache Kafka in production covers the rest of that architecture.

The first thing the tool has to survive is third-party and information security review. In the EU, DORA, Regulation (EU) 2022/2554, applies ICT risk and ICT third-party risk rules to the financial entities in the remit of the European supervisory authorities, and its Article 2 lists managers of alternative investment funds, management companies and institutions for occupational retirement provision among them, so a European fund manager or pension fund is in scope in its own right and not only through a banking parent. In Australia, Prudential Standard CPS 234 applies to every RSE licensee, the trustees of APRA-regulated superannuation funds, and requires them to stay resilient against information security incidents, including for information assets managed by related parties or third parties. Its paragraph 16 requires the trustee to assess the information security capability of any party that manages its information assets, and a footnote adds that this covers all such assets, not only those under a material outsourcing agreement. In the United States, the SEC’s amended Regulation S-P requires registered investment advisers and investment companies to oversee their service providers, and to have each one report a breach of a customer information system it maintains within 72 hours. All three rules concern a party that runs a system or holds data on the firm’s behalf. A management tool that runs as a component inside the firm’s own environment, with no database of its own and nothing between applications and brokers, leaves each of them the least to examine. A tool that routes client traffic through a vendor’s proxy, or stores state in an external database, adds to the review.

A Kafka tool reaches a cluster either as a client beside the applications or as a proxy that the applications connect through, and the two are sized and judged differently. Kai Waehner’s Kafka Proxy Demystified sets out that a proxy has to be deployed highly available and horizontally scalable or it risks becoming a single point of failure, because every client request passes through it. A client-side tool carries no application traffic, and Kpow’s minimum ACL documentation shows that the permission it needs on topics beyond its own internal ones is read access for features such as data inspect, so topic data is read only when a person asks for it, and the tool stays small however busy the cluster is. For a cluster designed around losing no trade instruction, that is the difference between adding a console and adding a component to the path every instruction takes. The property is not unique to the top-ranked tool, and the scores say so: Kafbat UI and AKHQ are also single stateless containers out of the data path and score the same 9 as Kpow on this criterion. Conduktor Console also connects to clusters directly and masks data in its own UI, but it needs an external PostgreSQL database, and Conduktor’s field encryption, masking of the data itself, policy enforcement on client traffic and Virtual Cluster multi-tenancy all run through Conduktor Gateway, which Conduktor’s own documentation describes as a Kafka proxy between client applications and brokers. The trade runs in both directions, because Gateway can enforce policy on applications and a client-side tool such as Kpow does not attempt that. A client-side tool is also the easier one to leave, since adopting or removing it changes nothing about how any application connects, while a proxy has to be taken out of every client’s connection path before it can be retired. That is the kind of exit a European firm has to plan for under DORA Article 28, whose paragraph 8 requires exit strategies for ICT services that support critical or important functions.

The second is control over who reads production. When a trade instruction fails, a valuation feed stalls or a client record looks wrong, an engineer needs to look at the production topic, but standing read access to client and member data is what the firm’s controls exist to prevent. So access has to be granted for a task, expire on its own and leave a record, and the fields that identify a client should be masked for the people who browse topics. The time available for that task has also shrunk, because since May 2024 most US securities transactions settle on the first business day after the trade, broker-dealers have to aim to complete allocations, confirmations and affirmations by the end of trade date, and the SEC’s books and records rule requires an investment adviser to keep each allocation and affirmation with a date and time stamp. A failed instruction therefore has to be found and fixed within hours, and an access process that takes days pushes a team towards the standing production access its controls are meant to prevent. Kafka itself offers no middle path, because a Kafka ACL names a principal, an operation and a resource and carries no end time, so access granted at the broker stays until somebody remembers to remove it, and a grant that ends on its own has to come from the tool. APRA’s guidance to superannuation trustees points the same way: Prudential Practice Guide CPG 234 lists regular reviews of user access by information asset owners, and a two-person rule on the most sensitive assets, among the access controls a regulated entity would typically deploy. For EU firms, DORA Article 9 limits access to information and ICT assets to what is required for legitimate and approved functions and activities only. A grant that expires leaves nothing standing for the next access review to find, and a change held for a second person’s approval is the two-person rule applied to a Kafka operation.

The record matters as much as the grant: when people work through a shared tool, the broker only sees the tool’s service account, so only the tool’s own log can name the person who read or changed a topic. CPG 234 states the principle that use of, and access to, information assets is attributable to an individual and that the activity is logged and monitored, and its attachment on identity and access lists prohibiting the sharing of accounts among the controls a regulated entity would typically deploy, with a possible exception for generic accounts where sharing is unavoidable due to technology constraints. A Kafka principal shared by a whole team is that kind of generic account, and a tool that each person signs in to as themselves removes the constraint. The same attachment lists audit logging and monitoring of access to information assets by all users, which for client data means reads as well as changes. In the United States a missing read log has a direct cost, because under Regulation S-P a firm that cannot identify which individuals’ sensitive information was accessed without authorisation has to notify everyone whose information sits in the affected system, within 30 days. A log that shows which topics a compromised account searched is what keeps that notification to the clients concerned. CPS 234 gives a superannuation trustee 72 hours to notify APRA of a material incident, which is little time to reconstruct who read what from broker logs that name only a service account.

What has to be hidden differs between the three kinds of firm. Member records at a superannuation fund carry tax file numbers, and the Australian privacy regulator’s guidance on the Tax File Number Rule names the trustee of a superannuation fund among the recipients that must restrict access to records containing them to the staff who need to handle them, and suggests audit trails to monitor that access. At a wealth manager the identifying fields are names and account numbers, and the account number is often the record key and not a field in the value, so masking has to reach keys and headers as well as values. At an asset manager much of what is sensitive is not personal at all: open orders and unpublished holdings are market-sensitive whoever the client is, and masking a name does nothing to hide a position, so for those topics the control is who can see the topic in the first place. Masking that is the same for every viewer also forces a choice on the operations team that owns a client topic and needs the real account number to do its work, because the field is either masked for that team too or clear for everyone the topic is open to. That is why exemptions per user or group score highest on this criterion, and why Conduktor Console scores above Kpow on it.

Around that sit the constraints most of these firms share. People are managed in Active Directory or Entra ID, often through SAML. Sign-in has had the regulator’s attention in Australian superannuation since 2025, when credential stuffing attacks on several funds led APRA to write to every RSE licensee expecting multi-factor authentication or an equivalent protection for privileged access and high-risk activities. A tool that signs people in through the firm’s identity provider inherits whatever second factor the firm enforces there, while a tool with local accounts is one more place where it has to be added. Two sign-in layers also tend to be merged in tool evaluations and are worth testing separately. SAML, OpenID Connect and LDAP are how a person signs in to the tool, while Kerberos, SCRAM and mutual TLS are how the tool authenticates to the brokers, and the Apache Kafka security overview lists them as Kafka’s own SASL and SSL mechanisms.

A group with separate asset management, wealth management and advice businesses runs them on the same few clusters, and each business should see only its own topics, consumer groups and connectors. In this sector that separation is a legal duty as well as good housekeeping. US investment advisers have to maintain and enforce written policies to prevent the misuse of material, nonpublic information, and the FCA Handbook defines a Chinese wall as an arrangement that requires information held in one part of a business to be withheld from people acting in another. On a shared cluster that wall has to hold inside the tool. Permissions on actions do not by themselves decide what a person can see, because cluster-wide views and totals still describe every business’s workload unless the tool also scopes visibility. Giving each business its own cluster is the other way to draw the line, and it ages badly in a sector where firms are bought, merged and reorganised as often as they are here, since every reorganisation moves the boundary. The Apache Kafka multi-tenancy guide documents the alternative, one cluster with a topic namespace per tenant, authentication and authorization, and quotas, and a boundary drawn in policy can be redrawn without moving data.

The size of the team shapes the bill as well as the controls. A firm of this kind has a few platform engineers and a much larger group of occasional users, developers, operations analysts and support staff, who each need to look at a topic a few times a month. Pricing per seat charges for every one of them and pricing per cluster does not, and the effect runs in both directions. On the published prices in this page’s cost model, $1,200 a seat against $4,500 a cluster, four clusters cost the same as 15 seats, so a team smaller than that pays less per seat and a larger one pays less per cluster. Claritev’s case study reports the same comparison from the buyer’s side, with per-cluster pricing coming out ahead of a per-user competitor at about forty users.

What asset and wealth managers use Kpow for

Five current Kpow customers come from this sector and are named here: Vontobel, a Swiss private bank and investment manager; Western Asset and Wellington Management, two US institutional asset managers; Insignia Financial, an Australian superannuation and wealth group; and Luma Financial Technologies, a US platform that serves financial advisers. None has published how it runs Kafka or what it uses Kpow for, so each card describes the firm from its own public sources rather than its Kpow setup.

How an asset or wealth manager runs its Kafka with Kpow

The workflows below are how an asset or wealth manager’s platform team puts Kpow to work across its Kafka clusters. Each one is built from documented Kpow features.

Install it inside the firm’s own environment. Kpow runs as one Docker container or Java JAR, or on Kubernetes with the Helm charts, inside the firm’s own network. It connects to the brokers as an ordinary Kafka client with the same cluster security settings as any other client, and it needs no external database: its system requirements state that snapshots, metrics and the audit log are held in topics on the firm’s own cluster and that Kpow has no dependencies beyond Kafka. The mechanism is Kafka’s own, since Kafka Streams keeps application state in internal topics on the cluster, so there is no second store of topic metadata or audit records for the firm to classify, secure and back up. Applications keep talking to the brokers directly, and no client data leaves the firm’s environment, which keeps the answer to a DORA or CPS 234 third-party question short. Because Kpow is a client, the brokers authorize it like one, and its documented minimum ACL permissions let the security team give its principal least privilege. The trade-off of keeping state in Kafka is that Kpow is available only while that cluster is, and the system requirements add that it has to run close to the clusters it manages, because network latency affects what it can observe, and that one installation spanning several regions is not officially supported. One instance connects to self-managed Apache Kafka, Confluent Platform, Confluent Cloud and Amazon MSK together, up to 12 clusters, so a larger fleet, or one spread across regions, runs more than one instance.

Give each business its own tenant. When a new team or business comes onto the platform, the platform team adds a tenant scoped to that team’s topics, consumer groups and connectors, so the wealth business does not see the asset management topics on the same cluster. Inside a tenant a user sees what the multi-tenancy documentation calls a fully consistent synthetic view of the cluster, aggregated over the tenant’s own resources, and can only create resources that are valid inside it, so an information barrier between two businesses holds in the lists and charts as well as in the permissions. Tenants are declared in the same configuration file as the RBAC policies and assigned to roles, so the definition of the barrier is one file that compliance can read and version control can track. RBAC then sets Allow, Deny or Stage per action and resource, with Deny winning where policies overlap, so production can stay read-only for everyone outside the operations team.

Sign people in through the directory. People sign in with SAML, including Microsoft Entra ID, OpenID or LDAP, and directory groups map to roles, so what each person can do in Kafka follows the groups the firm already manages and nobody keeps a separate list of Kafka users. With LDAP the roles are read from directory groups by Jetty’s JAAS LDAP login module, so Kpow keeps no user store of its own, and with SAML or OpenID the second factor is whatever the identity provider enforces. Kerberos belongs to the other layer only: it is one of the mechanisms Kpow can use to connect to brokers, and it is not a way for people to sign in.

Grant production access for one task. An engineer who needs to inspect a production topic raises a request in the firm’s change system. Once it is approved, that system calls the Kpow API to create a temporary policy that grants inspect access on the named topic for the time the task needs. The policy expires on its own, is capped at seven days by default, and is recorded in the audit log. An administrator can also choose a custom expiry date and time, so a grant made to fix a failed instruction can end at the day’s affirmation cut-off instead of after a round number of hours. Access that is refused leaves a trace as well, because each audit record carries the authorization result and the policies that were evaluated, so an attempt to read a topic outside a grant shows up in the trail.

Mask client and member fields. Data policies redact names, account numbers and other client fields in Data Inspect and ksqlDB results on the server, on keys, values and headers and inside Avro, Protobuf and JSON structures, so an engineer fixing a failed instruction sees the structure of each message without the client’s identity. A tax file number in a member record, or an account number used as the record key, is redacted the same way as a field in the value. While policies are active, the String SerDes is removed from Data Inspect so a raw read cannot get round them, and topics that carry no client data can be excluded. A policy is set per resource and applies to every viewer, so it cannot show the team that owns a client topic the real value and everyone else the masked one, which Conduktor Console can; and like every UI on this page, Kpow masks what people see, not what is stored or what consumers read.

Hold risky changes for a second person. With staged mutations, a role can be set to Stage on actions such as resetting a consumer group’s offsets or deleting a topic, so the request waits in Kpow until an administrator approves or denies it, and the full history lands in the audit log. A staged request expires after 15 minutes by default, and the window can be lengthened with the scheduler setting. An offset reset on a trade or instruction topic replays messages to the consumer, which is safe only when the messages can be processed twice without harm. The Goldman Sachs team in the InfoQ account put a globally unique identifier on every message for that reason, so that messages resent after an outage create no duplicates. Where a topic has no such identifier, holding the reset for a second person is the control that stands in for it.

Show the risk team who did what. The audit log records each action, data inspect queries included, with the user from the firm’s directory and the policy that allowed it. Kpow shows the last seven days in the product and writes every record to the __oprtr_audit_log topic on the firm’s own cluster, which keeps one week by default and longer if the firm configures Kafka to keep it, and webhooks send mutations, data inspect queries or both to Slack, Microsoft Teams or the firm’s SIEM, where the firm’s own retention rules apply. The webhook’s verbosity setting separates the two, so a chat channel can receive only the changes while the SIEM receives every data query. Retention is the part to plan, because an incident is often discovered months after the access took place and a topic that keeps one week of records cannot answer for it, so the firm either raises the audit topic’s retention or treats the SIEM as the system of record.

Watch lag on pricing and valuation feeds. Kpow publishes consumer group offsets and lag, with broker, topic and connector metrics, on Prometheus endpoints for Grafana, AlertManager or the firm’s own monitoring, so a consumer that falls behind on a price or valuation feed raises an alert before the numbers reach a client report. Lag alone misses a common feed failure, because when a price source stops publishing its consumers catch up and report no lag at all, so the signal to alert on is the topic’s write rate falling to zero, which Kpow computes from the offsets it observes and exports beside lag, as the article on high-fidelity metrics for Grafana describes. Kpow has no alerting engine of its own, so the alert rules live in the firm’s Prometheus or other monitoring.

Keep broker ACLs for services. Kpow governs people working through Kpow, not services connecting to brokers, so broker ACLs or an authorizer remain the control for applications. The two layers are checked independently: a person needs the permission in Kpow, and Kpow’s own principal needs the matching ACL at the broker, which stays the final authority on every action.

Govern Flink jobs the same way. Firms that run Apache Flink beside Kafka can put the same directory sign-in and Allow, Deny or Stage policies over their Flink jobs with Flex.

To see these screens before installing anything, the live Kpow demo needs no signup and shows what an asset manager’s engineers do every day, data inspect, consumer groups and topic management, on two MSK clusters, with the audit trail in the __oprtr_audit_log topic on MSK Secondary. The demo has no SSO and no data policies configured, so sign-in and masking are the two things to test in the firm’s own environment. To run the workflows against the firm’s own clusters, install Kpow from its container image or JAR; single sign-on, tenants, RBAC, temporary policies, staged mutations, masking and the audit log are Kpow Enterprise features, and Community Edition is free for 3 clusters and 10 users but holds none of them.

Kpow live demo

Open Kpow the way an asset manager's engineers would

The live Kpow demo needs no signup. Browse clusters, consumer groups and topic data, then read the audit trail on the __oprtr_audit_log topic of the MSK Secondary cluster.

For platform teams running Kafka under client, holdings and member data.

Try the Kpow demo→

FAQ

What is the best Kafka tool for an asset manager or wealth manager?

On this page’s rubric, Kpow: it runs as one container inside the firm’s own environment with no external database and nothing in the data path, grants time-boxed production access through its API, records every action and data query with the person from the firm’s directory, masks client fields on the server, and scopes each team with tenants. Kafbat UI is the strongest free option, but it has no expiring access grants and no view of its audit trail. Conduktor Console scores higher on who can see unmasked data. Kpow also has a free Community Edition for up to 3 clusters and 10 users, without the governance features: RBAC, masking, temporary access and the audit log are Enterprise.

Do asset and wealth managers need a different Kafka tool from banks?

The tool can be the same, but the priorities differ. This page keeps the bank rubric’s weight on staying out of the data path, production access and the audit trail, and adds who can see unmasked data, because client and member records sit in the topics, in place of on-prem plus cloud. The banking page scores on-prem plus cloud for platform teams that serve hundreds of projects across both, and the financial services page maps each regulation to a Kafka control.

Does CPS 234 apply to Kafka at a superannuation fund?

CPS 234 does not name Kafka or any technology. It applies to every RSE licensee and requires information security over the fund’s information assets, including assets managed by third parties, so Kafka clusters that carry member data, and any tool that can read them, fall within its scope. A management tool that runs inside the fund’s own environment, names the person behind each action and masks member fields for the people who browse topics helps the trustee show that control.

How should a wealth manager mask client data in Kafka?

In two layers. Fields that no reader needs in plaintext are best encrypted or removed on the write path, before they reach the broker. Fields that engineers do need to see the shape of are masked at view time in the management tool, which in Kpow means data policies applied on the server to Data Inspect and ksqlDB results. Best tools for Kafka data masking compares both layers.

How should an asset manager give engineers access to production Kafka data?

Grant it per task rather than permanently: a request, an approval, access to a named resource for the time the task needs, and a record of the grant and of what was read. In Kpow that is a temporary policy, which a change system can create through the API, and which expires on its own.

Does a Kafka management tool need to be a proxy to govern access?

No. Governing what people can see and do in a tool, with RBAC, masking in inspection and an audit log, works from a tool that connects as an ordinary Kafka client. A proxy is only needed to enforce policy on application traffic, and it puts a component between the brokers and every application that routes through it.

Can an asset or wealth manager run Kpow with no internet access?

Yes. Kpow runs fully offline with no data leaving the firm’s environment, and works the same way in an air-gapped network as anywhere else. Its snapshots, metrics and audit log are held in topics on the firm’s own cluster, so beyond Kafka it has no further dependencies: no external database and no vendor-hosted service.

How these tools were scored

Six criteria, each taken from a situation asset managers, wealth managers and superannuation funds face under DORA, CPS 234 or day-to-day operations, score every option from 0 to 10. They are listed here in order of weight.

1. Out of the data path. A management tool that runs in the firm’s own environment, connects as an ordinary Kafka client and keeps no data outside the firm’s clusters gives the shortest answer when the firm asks which third parties can see its client and member data. Scored lower: tools that need an external database, and tools whose controls work only when application traffic passes through a vendor’s proxy. A self-hosted container with no external database and no proxy scores 9, a tool with a database of its own 6, one with several databases or a component on the brokers 4, and one that needs both a database and a proxy for its controls 3; 10 is kept for an option with nothing to deploy at all. This criterion is scored the same way on every Factor House page that uses it, and only its weight changes with the reader.

2. Production access on request. Can an engineer be given read access to a production topic for a task, approved and time-boxed, without a standing grant? Can production changes such as offset resets be held for a second person’s approval? And is client data masked for the people who do get in? Criterion 4 then scores masking more closely: who can be exempted from it and whether it can be bypassed. The wider set of controls over deletes and offset resets is compared in best tools to control destructive Kafka operations.

3. Audit trail per person. When people work through a shared tool, the broker only sees the tool’s service account, so only the tool’s own log can name the person. An asset or wealth manager needs that log to include data reads as well as changes, so it can show who looked at a client’s records as well as who changed a topic, and to be readable without building a consumer first. Best tools for Kafka audit logging compares the layers in detail.

4. Who can see unmasked data. Client names, account numbers and holdings sit in topic payloads. Scored on whether the tool masks fields on the server, whether a raw read can get round the masking, and whether the team that owns the data can be exempted while everyone else sees masked values. Exemptions per user or group score highest among the management tools, server-side masking with a guard against bypass next, the same masking for every viewer lower, and no masking lowest. Every tool that best tools for Kafka data masking scores gets the same score here, and that page also covers write-path encryption; Confluent Control Center, which it does not score, gets 2 because no masking is described for its message browser.

5. Directory and Kafka sign-in. People should sign in through the firm’s directory, whether that is LDAP directly or SAML and OIDC in front of Active Directory or Entra ID, with directory groups mapped to roles. On the cluster side the tool has to connect the way the firm’s clusters already authenticate clients, whether that is SASL, Kerberos or mutual TLS. Best tools for Kafka SSO integration covers the protocol detail.

6. Many teams, shared clusters. A group with separate asset management, wealth management and advice businesses runs them on a handful of clusters, so the platform team needs to scope each team to its own topics, consumer groups and connectors and onboard a team with a policy rather than a cluster.

The cost figures model an asset or wealth manager running 4 clusters (development, test, production and disaster recovery) for 50 engineers at $120 an engineer-hour, and each card prints its own assumptions. The general listicle view, without the asset and wealth management weighting, is in best Kafka management tools.

F1 What an asset or wealth manager runs into, and what the Kafka tool has to do about it

What happens at an asset or wealth manager What the Kafka tool has to do

Third-party review Risk and information security review every component that can see client, holdings or member data Run inside the firm's own environment as a Kafka client, with no external database and no vendor proxy

Reading production data An engineer needs to see what is in a production topic to fix a failed trade instruction or a stuck valuation feed Grant read access on request, time-boxed, through an API a change system can call, and record the grant

Client and member fields Topics carry client names, account numbers and holdings Mask those fields on the server for the people who browse topics, and keep the masking from being bypassed

Who did what Risk, audit or the regulator asks who read or changed a production topic Log each action and data query with the person from the directory, on the firm's own infrastructure

Directory sign-in People and groups live in Active Directory or Entra ID Sign people in through that directory and map its groups to roles

Several businesses Asset management, wealth management and advice teams share a small number of clusters Scope each team to its own topics, consumer groups and connectors

Every option is scored from 0 to 10 on each criterion, from the evidence and sources this page cites, and the reason for each score is on its card. The criteria are weighted: Out of the data path counts three times, Production access on request counts twice, Audit trail per person counts twice, Who can see unmasked data counts once, Directory and Kafka sign-in counts once and Many teams, shared clusters counts once, for a total out of 100. Out of the data path counts three times because DORA in the EU and CPS 234 for APRA-regulated superannuation trustees both hold a firm to account for the ICT and information assets that third parties touch, and a tool that sits between applications and brokers, or keeps its state in a database of its own, is more to review and one more place client data can go. Production access and the per-person audit trail count twice, because they are the controls a risk team and a regulator ask about first: who could read or change production, and who actually did. Who can see unmasked data, directory sign-in and shared clusters count once; masking in a management tool hides client fields from people browsing topics but does not change what is stored or what applications read, so it comes after the question of who gets in at all. This page is published by Factor House, which makes Kpow. Every option is scored on the same rubric and the same sources: Kpow's per-criterion scores are set the same way as every other option's and are not adjusted, and the weights apply to every option alike. Kpow ranks first on its total of 87 out of 100. The other options follow by total. Conduktor is listed last whatever its total; on its total of 58 it would place third.

Related reading

• Kafka: the complete guide
• Best Kafka governance tools for financial services
• Best Kafka management tools for banks
• Best tools for Kafka data masking
• Best tools for Kafka audit logging
• Running Kafka at bank scale: TD Bank