Why embedded analytics for financial services is a different build
A bank, fintech or wealth manager that wants clients and advisers to see their own positions, fees or performance inside the portal will find that the charts are the easy part. The hard part is per-client isolation, entitlement mapping and audit. Every query must return only the rows that the logged-in client or adviser is allowed to see, the entitlement must come from the portal's identity system rather than a list maintained by hand in the BI tool, and the institution must be able to show later who viewed which figures. For most institutions, Apache Superset is the stronger starting point: it is licensed under Apache-2.0 with no paid edition, so the embedding path, row-level rules and role mapping can be owned and controlled in full. Metabase is a credible alternative, but its row-level permissions, SSO and multi-tenant segregation sit in the Pro and Enterprise plans, so that cost belongs in the budget from the first day, not after a pilot.
Reporting deadlines are a load problem before they are a feature problem. Quarter-end statements, fee runs and adviser packs concentrate queries into short windows, and if dashboards read directly from the core banking or custodial database, a deadline can slow the systems that process transactions. Superset's architecture documentation describes an optional caching layer and Celery workers for alerts, reports and async queries, and the reader should confirm how those components would be sized and scheduled for their own calendar. Plan a read replica or a separate analytical store, and test peak load against the real quarter-end volume rather than an average day.
All of this should stay in the institution's own infrastructure. Client positions, account identifiers and fee data are exactly the material that regulators and clients expect to remain under the institution's control, and a self-hosted deployment keeps the metadata database, the caches and the audit logs inside the same boundary as the data. Before choosing a platform, confirm in writing where each component runs, who holds the encryption keys and how the audit trail is retained and exported to the institution's logging system.
Which regulatory requirements shape the dashboard build
This table maps each regime that often applies to a financial entity's client portal to the concrete dashboard build decision it drives. Read it by first confirming which regimes apply to your entity type, then using the build decision column to scope the architecture, access model and exit plan. Applicability depends on your license, payment role and jurisdiction, so confirm it with your compliance and legal teams before scoping.
| Requirement | What it asks for in the build | Where it usually fails |
|---|---|---|
| PCI DSS v4.0.1 cardholder data scope | Decide whether dashboards touch cardholder data or could affect the cardholder data environment. If they do, isolate the reporting database, restrict access by role and keep card fields out of embedded queries. | Teams assume dashboards are out of scope because they are read-only, then pull full transaction tables into the reporting store. |
| DORA Article 28(3) register of ICT arrangements | Record the open-source components, hosting provider, DeployOpen engagement and any support retainer as contractual ICT arrangements in the register. | Self-hosted open source is treated as having no provider, so the implementation partner and cloud host are left off the register. |
| DORA Article 28(8) exit strategy | Document and test how dashboards, saved queries, metadata and users are moved or retired if the platform or partner changes. | Exit plans cover the database but not the BI metadata, embedding configuration or the entitlement mapping. |
| DORA Article 30(2) contract content | Specify in the contract where services are provided and data is processed, advance notice of location changes, and data return on termination or insolvency. | Contracts name a country for the vendor but not for backups, support access or log storage. |
| SEC Release 33-8810 IT general controls | Evidence controls over program changes, computer operations and access to programs and data for dashboards that feed financial reporting. | Dashboards built for client reporting are not inventoried, so changes to measures or filters bypass change control. |
| FTC Safeguards Rule, 16 CFR 314.4(c)(5) | Require multi-factor authentication for any individual accessing an information system, unless the Qualified Individual approves an equivalent control in writing. Apply this to internal adviser access as well as clients. | Adviser consoles and admin accounts are left on single-factor login while the client portal enforces MFA. |
| NIS2 and GDPR context | Where applicable, keep personal data in approved locations, define processor roles in contracts and document security measures for incident reporting. | Analytics copies of personal data spread into exports, caches and logs that are not covered by the processing record. |
| Swift CSCF v2026 (if Swift users) | Where the entity is a Swift user, plan independent assessment of the controls covering the systems that handle Swift data and annual attestation in KYC-SA. | Reporting systems that pull Swift message data are left out of the assessed scope. |
Which client data and systems the dashboards touch
The first decision is which systems feed the dashboards, because that determines who is in scope for each control. The usual path runs from core banking, custody, card processing or CRM systems into a reporting database, which is then queried by the analytics application. The analytics application keeps its own metadata database for users, dashboards, roles and saved questions. Each hop is a separate place where client data is copied, cached or logged, so the data inventory should list every hop with its owner, its retention and the people who can read it. Ask the business owner of each source system to confirm which tables and fields a client-facing view actually needs, and treat anything else as out of the first release.
Keep the analytics database separate from the production core. A read replica, a reporting copy or a warehouse loaded on a schedule gives the dashboards a stable target and keeps reporting queries away from transaction processing, especially at month-end and quarter-end deadlines when adviser and client portals spike. Confirm the replication lag your business accepts, who operates the copy and whether the copy inherits the production access model. Where a view allows it, replace account identifiers with tokens or pseudonyms before data reaches the analytics layer, and keep the token-to-account mapping in a separate, more tightly controlled store. Cardholder data needs particular care: if card transactions appear in any dashboard, the reporting path, the analytics host and the metadata database may fall within the scope of PCI DSS, so keep primary account numbers out of the analytics database altogether and have a qualified assessor confirm the boundary before go-live. The PCI Security Standards Council describes which entities and systems the standard covers.
Superset or Metabase for a client-facing financial portal
Apache Superset is an Apache Software Foundation project under the Apache License 2.0, and the project has no paid edition. That makes licensing simple to explain to a risk committee, and it avoids a commercial feature gate for SSO or row-level controls. The latest stable release in the supplied facts is 6.1.0, published May 13, 2026. Superset is built on Flask-AppBuilder and supports OAuth2 providers and LDAP, with group-to-role mapping through AUTH_ROLES_MAPPING.
- Identity mapping: Portal entitlements can flow into Superset through OAuth2 or LDAP groups mapped to roles, which keeps authorization tied to the portal's identity system.
- Required components: Alerts, reports, async queries and thumbnails need the caching layer and Celery workers, so a production design includes Redis and worker processes.
- Metadata database: Superset is tested with PostgreSQL and MySQL for production, and the SQLite default is not recommended.
- Deployment path: The Helm chart is marked deprecated in current development documentation, which points new Kubernetes deployments to the Apache Superset Kubernetes Operator.
- Upgrade discipline: Each upgrade requires a metadata database backup,
superset db upgrade,superset init, staging tests and a review of UPDATING.md.
Ask the implementation partner to demonstrate per-client row-level filtering in your own environment, since the open source tier is the only tier in this comparison and every control must be built and tested by your team or the partner.
Metabase ships its open source edition under the AGPL and its commercial editions under the Metabase Commercial Software License. The backend runs as a JAR written in Clojure and Java. The pricing page lists Open Source, Starter, Pro and Enterprise plans. According to that page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in Pro and Enterprise. Enterprise is priced by quote, starting at $20,000 per year. Confirm current figures directly with Metabase before any budget decision.
- Paid-tier controls: Row and column permissions, multi-tenant segregation and usage auditing are paid-plan features in the pricing page's description, so they belong in the cost model from the start.
- Authentication options: JWT, OIDC and SAML, including documented setups for Entra ID, Okta and Keycloak, require Pro or Enterprise. SCIM provisioning and advanced LDAP group sync also sit on paid plans.
- Long-term support: Metabase 64 is an LTS release published September 16, 2026, with end of life on December 1, 2027. Metabase 65 was released October 12, 2026.
- Application database: Production should use PostgreSQL or MySQL rather than the embedded H2 database, and the one-time load-from-h2 command must run on the same version that last wrote the H2 file.
- AGPL obligations: If you modify Metabase code and make it available to users over a network, including inside a client portal, the AGPL source obligations apply to those modifications. Get legal review before modifying the code.
Confirm the exact plan that includes JWT or SAML embedding for your user counts, and ask the vendor how usage auditing exposes who viewed which client's data.
Per-client segregation in a financial portal depends on how entitlements are carried from the portal's identity system into the analytics layer, and on whether each view can be attributed to a named user. Superset maps groups to roles and can enforce row-level security through its own configuration. Metabase places row-level permissions, multi-tenant segregation and usage auditing behind its paid plans. Either way, the design must prove that an adviser sees only mandated clients and that the record of access can be produced for review.
- Source of truth: Entitlements should come from the portal's identity provider or entitlement service, not from manually maintained analytics users.
- Row-level tests: Build test accounts for each client and adviser role, and check that every dashboard, filter and export returns only permitted rows.
- Audit records: Log the user, client scope, dashboard, query and time for each access, and store those logs where the firm's retention rules apply.
- Deprovisioning: Removing an adviser from a group must remove dashboard access on the next session, and the process needs to be tested.
- Financial regulation mapping: Access control and logging support evidence for frameworks such as the FTC Safeguards Rule for non-bank institutions and SEC IT general control areas, but DeployOpen prepares that evidence without issuing any attestation.
Ask for a written test plan that shows how each entitlement change is verified and logged, and confirm that the audit trail is complete for client-scoped views.
Client reporting cycles, such as month-end statements or quarter-end performance packs, concentrate many dashboard queries in a short window. The analytics platform must not push that load onto the core transaction systems. Both Superset and Metabase can point at a separate reporting database, and the design choice is about caching, worker capacity and the database behind them. Superset's async queries and scheduled reports rely on its caching and worker components, which must be sized for peak use.
- Separate reporting store: Serve dashboards from a read replica, a reporting warehouse or a data mart rather than from production core banking tables.
- Caching and workers: Superset deployments that use alerts, reports or async queries need Redis and Celery sized for the deadline peak. Test that scheduled reports finish before client delivery windows.
- Metabase application database: Use PostgreSQL or MySQL for the application database, and back it up before any upgrade. For major upgrades, the docs recommend reducing a cluster to a single node because of a migration lock, so schedule upgrades outside reporting windows.
- Load testing: Replay a realistic month-end query mix against staging and record response times per dashboard.
- Capacity planning: Ask the partner to document scaling steps and the owner for each.
Confirm the expected concurrent viewers and report run times with your business owners before the design review, and ask for a load test result from your staging environment rather than a general benchmark.
How the embedding and identity path should be laid out
This sequence turns a portal's identity system into the single source of truth for who sees which client's data in the analytics layer. Each step ends with a check that proves the entitlement path holds before any client sees a dashboard.
Place the analytics stack in a segregated zone
The network team places the analytics application, its metadata database, cache and workers in a dedicated zone that accepts traffic only from the portal's embedding service and from named administrator hosts. Analytics services do not connect directly to the core banking or card data environment, and the source databases accept connections only from a read-only analytics account. The step is done when a connectivity test from the analytics zone to the production data tier succeeds only on the approved read replica path and fails everywhere else. Confirm with your security team how this zone maps to your cardholder data environment scope under PCI DSS, if it applies to your organization.
Deploy PostgreSQL as the metadata database
The platform engineering team provisions a PostgreSQL instance for the application's metadata, which holds dashboards, datasets, users, roles and audit records. Superset's documentation supports PostgreSQL 10 to 17 for this purpose and advises against the SQLite default for production. Metabase's documentation recommends PostgreSQL for production and documents a one-time migration from its embedded H2 database. The step is done when the metadata database is backed up on a schedule, restored successfully in a test environment, and reachable only from the analytics application nodes.
Add the cache and workers for scheduled jobs
The platform team adds the caching layer and Celery worker and beat processes that power alerts, scheduled reports, async queries and dashboard thumbnails. Superset's architecture documentation states that these features require the caching layer and worker components, and most installations use Redis and Celery. The step is done when a scheduled report runs from the worker, the cache holds its results, and the worker nodes sit inside the same segregated zone as the application. Ask the vendor or partner which of these jobs will run against client-level data, since each one needs its own entitlement check.
Manage the SECRET_KEY and its rotation
The security team generates a unique SECRET_KEY for each environment and stores it in a managed secret store, never in source control or a plain configuration file. Superset requires a user-specified SECRET_KEY to start, and it supports rotation through PREVIOUS_SECRET_KEY, which lets the platform accept sessions signed with the prior key during the change window. The step is done when the key is loaded from the secret store at startup, a rotation has been rehearsed in staging, and the rotation procedure is written into the runbook with an owner named for each action.
Connect the portal identity provider
The identity team configures single sign-on so that the analytics application trusts the same identity provider as the client and adviser portals. Superset supports OAuth2 providers and custom OAuth2 servers using the code flow, along with LDAP, and it maps groups to roles through AUTH_ROLES_MAPPING. Metabase's open source and Starter plans support Google sign-in and LDAP, while JWT, OIDC and SAML single sign-on, and SCIM provisioning, require its Pro or Enterprise plans according to its pricing and people documentation. The step is done when a test adviser and a test client each sign in through the portal's provider and land in the correct workspace.
Issue signed embedding tokens per session
The portal's backend requests a short-lived, signed embedding token for each dashboard view, and the token carries only the client or adviser identifier and the dashboard to be shown, with the row-level filter applied on the analytics side. The portal never sends raw database credentials or open query parameters to the browser. Confirm the exact embedding method and token options with the vendor, because embedding features and their plan requirements differ between products and versions. The step is done when a token issued for client A returns no rows belonging to client B in a negative test.
Derive client and adviser roles from the entitlement source
The identity team maps adviser and client roles from the same entitlement source the portal uses for account access, so a change in the portal's entitlement record flows to the analytics application without a second manual list. Group-to-role mapping in Superset and group sync in Metabase both depend on this single source. The step is done when a revoked adviser entitlement removes dashboard access within the sync cycle set by the identity team, and an audit query confirms the change. Avoid maintaining a separate role table inside the analytics application, because it will drift from the portal over time.
Test segregation before any production release
The assurance team runs a documented test set against staging that includes cross-client access attempts, expired and tampered tokens, revoked entitlements and a reporting-deadline load test on the read path. Results are recorded with the version of each component, so the evidence can be shown to internal audit and to an independent assessor. Superset's upgrade guidance also calls for testing in staging before each upgrade. The step is done when every negative test fails closed, the results are signed off by the business owner, and the evidence package is stored with the change record.
How a financial services rollout proceeds
The sequence moves from agreed entitlements and data classes to a tested, controlled go-live and handover, so each stage produces evidence that client data stays segregated and that the reporting platform holds up at deadlines. Each phase has a named output that the next phase depends on.
Scope entitlements and data classes with compliance
Your compliance, data protection and portal owners agree which client, adviser and staff roles exist, which data classes each role may see, and which datasets carry cardholder or other regulated data in scope of PCI DSS. DeployOpen maps these rules to the portal's identity provider groups and documents where each rule is enforced. The step closes with a signed entitlement matrix and a data classification register that name the source system for every dataset.
Build a cross-client segregation test suite
Before dashboards are built out, DeployOpen writes automated tests that authenticate as users from one client and attempt to reach dashboards, datasets, filters, saved questions, exports, embed tokens and API endpoints belonging to another client. Tests also cover adviser accounts with multiple client books and revoked or changed group memberships. The step closes when the suite runs in a repeatable pipeline and every expected denial is recorded as a passing result.
Stage with production-like volumes and a deadline load test
The platform is deployed to a staging environment with a metadata database on PostgreSQL or MySQL, a sanitized or synthetic copy of production-shaped data, and the caching and worker components the chosen tool needs for scheduled reports. DeployOpen then runs a load test that replays the reporting deadline pattern you supply, including concurrent adviser sessions and scheduled exports, and measures query times and database pressure. The step closes with a written results report that states which queries need a read replica, a warehouse or pre-aggregation before go-live.
Test the security of the embedding path
DeployOpen tests the portal-to-dashboard handoff as an attacker would: token or session forgery, replay of signed embed URLs, parameter tampering, SSO assertion handling, secret key management and exposure of the platform's admin interfaces. Findings are logged with severity and retest status. The step closes when no open high-severity findings remain in the embedding path and the retest results are filed with the evidence pack.
Run a controlled go-live with rollback
Access is opened first to a pilot group of clients and advisers chosen with your business owners, with the segregation suite re-run against production configuration. Access logs are checked for who viewed which client's data, and the team confirms that the audit trail is complete. A tested rollback path, including the metadata database backup taken before release, is held ready until the pilot period ends. The step closes with a go-live sign-off that records the pilot scope, the test results and the rollback decision point.
Hand over runbooks and operating procedures
DeployOpen delivers runbooks for user and entitlement changes, upgrades (including database backup, migration steps and staging tests before production), key rotation, incident response for suspected cross-client exposure and the deadline load test. Your operations staff run one supervised change as a rehearsal. The step closes when your team has completed the rehearsal and the runbooks, test suite and audit log procedures are stored in your own document system.
What auditors and examiners ask to see from the dashboards
This table maps each evidence item an examiner or auditor is likely to request to the control it supports, what the record should show, and where teams usually fall short. DeployOpen prepares the evidence, but the independent auditor, examiner or certification body draws any conclusion from it.
| Evidence item | What the record should show | Where it usually falls short |
|---|---|---|
| Entitlement matrix | Each identity group from the portal's identity system mapped to its row filters, with the client or adviser scope it grants and the owner who approved it | Row filters live only in the BI tool, drift from the portal's group model, and nobody can show the approval for a given mapping |
| Access review records | Dated reviews of who holds each dashboard role and row scope, the reviewer, the decisions taken and removals completed | Reviews cover application users but not service accounts, guest embedding credentials or former advisers still mapped to client data |
| Change logs for dashboards and roles | Who changed a dashboard, dataset, role mapping or row-level rule, when, with the ticket or approval that authorized it | Changes are made directly in the admin interface with no ticket, so program change and access evidence cannot be tied together |
| Upgrade records | Version before and after, the staging test results, the metadata database backup taken before running the upgrade steps, and the breaking-change review against the release notes | Upgrades run in production without a tested backup, or the team cannot show which Superset version was running on a given date |
| MFA enforcement evidence | Configuration showing the identity provider enforces multi-factor authentication for every user who can reach the dashboards, plus any written approval for an equivalent control | MFA is enforced at the portal but not on direct logins, admin accounts or the analytics database connection |
| Data location and sub-processor records | Contract-level statement of where the dashboards and underlying data are processed, the hosting accounts used, and advance notice of any change in location or provider | Hosting locations are described in the sales deck but not in the contract, and backups or support tooling in other regions are not listed |
| Register entry for the analytics service | An entry in the ICT services register covering the service, its provider, the functions it supports, the contract reference and the documented exit plan | The service is missing from the register because it was bought or built as a project, not as an ICT service |
Questions to put to an implementation partner
How do we enforce and test per-client row-level security in embedded dashboards?
Row-level security should be enforced by the analytics platform against each client's identity, not by hiding rows in the front end. Ask the partner which mechanism is used for each platform: Metabase's row and column level permissions are documented as part of its Pro and Enterprise plans, and Apache Superset can apply row-level filters through its security configuration. Then ask how the rules are tested: expect a written test plan with a set of client accounts that must see zero rows belonging to other clients, run on every release and after every change to the data model. Ask who signs off the test results and where they are stored as evidence.
How are entitlements derived from our portal identity system?
Entitlements should come from the portal's identity provider as group or attribute claims, so that the analytics platform never holds a separate, hand-maintained list of who may see what. Ask how groups are mapped to roles and filters: Superset maps LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING, and Metabase's JWT, OIDC, SAML and SCIM options require a paid plan in its published documentation. Ask what happens when an adviser loses a client relationship, how quickly that change takes effect, and whether a deprovisioning test is part of the handover.
How are embedding tokens signed and expired?
Embedding tokens should be signed with a key the bank controls, carry the client and entitlement scope, and expire within a short window. Ask the partner to show the signing key location, the rotation procedure and the expiry value used in production. For Superset, ask how the SECRET_KEY is generated, stored and rotated using PREVIOUS_SECRET_KEY, since Superset requires a user-specified SECRET_KEY to start. For Metabase, ask whether signed embedding or SSO is used and whether the chosen method is available on the plan being quoted. Request a written statement of what happens when a token is replayed or outlives a session.
How is reporting-deadline load kept off the core banking system?
Dashboards should read from a separate reporting store fed by a controlled extract, never from the transaction system directly. Ask the partner how the extract is scheduled, how often data is refreshed, and what the caching layer serves during a quarter-end peak. Superset's architecture documentation says alerts, reports, async queries and thumbnails need the caching layer and worker components, and most installations use Redis and Celery for them, so ask for the sizing and the load test plan. Also ask for the expected concurrency at deadlines, the query timeout settings, and who approves capacity changes before a known reporting date.
What do audit logs record, and where are they retained?
Audit logs should record who viewed which dashboard, which filters applied, which client scope was in effect and when, and they should be stored outside the analytics application's own writable storage. Ask the partner to list every log source, including the reverse proxy, the identity provider, the analytics application and the database, and where each is shipped. Ask for the retention period, the access controls on the log store and how logs are protected from tampering. For Metabase, ask which usage analytics and auditing features are included in the plan being quoted, since the pricing page limits them to Pro and Enterprise.
How are exit and data return documented for DORA?
A DORA-aligned handover needs written exit strategy, transition plan and data return terms that cover the self-hosted platform and its data. Ask the partner for the register entries that describe where services run and where data is processed, the procedure to export dashboards, datasets, users and metadata, and the tested steps for moving to another platform. Ask who holds the administrative credentials at handover and whether the exit plan has been exercised in a non-production environment. DORA Article 28 and Article 30 set the expectations here; confirm with your legal and compliance teams how they apply to your contracts.
Which Metabase features would require a paid plan?
Per Metabase's pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in the Pro and Enterprise plans, not in Open Source or Starter. Starter is listed at $100 per month, or $90 per month billed yearly, with the first 5 users included, and Pro at $575 per month, or $517.50 per month billed yearly, with the first 10 users included. Additional users cost $6 (Starter) or $12 (Pro) per month. Enterprise is priced by quote, starting at $20,000 per year. Confirm current pricing directly with Metabase, because these figures may change.
Can our own team run this, or do we need an implementation partner?
Your team can run the platform after handover, but the first build needs people who understand both the analytics platform and your identity and security controls. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms in your own cloud accounts or data centers, and most engagements are fixed-scope with scope and deliverables agreed in writing before work starts. Ask the partner which tasks they would hand over, which stay under a support retainer, and what evidence you receive at each stage. Ask for the written scope and the quote before deciding.
How DeployOpen scopes and supports this build
DeployOpen works from a fixed scope agreed in writing before any build starts. For a portal-embedded Superset or Metabase deployment, that scope should name each embedded path, the identity source feeding entitlements, the client-facing and adviser-facing roles, the deadline-driven reporting windows the platform must absorb, and the acceptance tests for per-client segregation. The platform is deployed into the client's own cloud accounts or data centers, so the metadata database, the caching and worker tier, and the analytics database connections stay under the client's control. DeployOpen does not publish a price list, so the quote should follow directly from that written scope. Ask for it to separate one-time work (architecture, identity mapping, hardening, documentation) from recurring costs (hosting, licenses where a paid Metabase plan applies, and support). Security testing covers the embedded paths specifically, not only the BI tool in isolation. Testing should attempt to reach another client's rows through guest tokens, signed embedding parameters, saved questions, export functions and API calls, and should confirm that the entitlement mapping from the portal's identity system holds when a user's group membership changes. DeployOpen also runs cloud and infrastructure testing against the hosting layer. Ask the testing partner to show which findings are retested before sign-off and how results are stored for the client's own records. DeployOpen prepares systems, controls and evidence for assessments such as those a financial institution faces under its own regulators or under standards like PCI DSS, but it does not issue audit reports, attestations or certifications. The evidence pack typically covers access reviews, configuration baselines, audit log retention and backup test results. Retainers are available for upgrades, continuous testing and ongoing support, which matters because Superset and Metabase both require database backups and staged upgrades. Confirm the retainer terms, response expectations and upgrade cadence in writing before the build is accepted.
