Business observability: measuring the banking customer journey

In banking, customers do not see servers or APIs. They see whether they could log in to the app, whether the transfer went through, whether the card was accepted at the store, whether they finished opening their account. Yet much of today's monitoring still measures what customers do not see: server availability, average response times, resource usage.

Business observability closes that gap. It means instrumenting customer journeys as business transactions, with metrics the business understands, and placing them next to technical metrics. The goal is concrete: detect a degradation while it still affects few customers, and know which component is causing it.

Why the technical traffic light is not enough

A full outage is noticed right away. What is hard to detect is partial degradation:

• Transfers to other banks fail, while transfers within the bank work.
• Card payments are declined only for one merchant type or one card brand.
• Login works on the web but fails on a specific mobile app version.
• Onboarding stalls at the identity verification step because a provider responds slowly.

In all these cases, aggregated technical indicators can stay green. The overall error rate barely moves because the affected segment is small, and average latency hardly changes. The first warning comes from the call center or social media. By then, the impact is visible to customers and, sometimes, to the regulator.

Journeys as business transactions

Instrumenting a journey means that each relevant step emits an event with its business outcome, not just its HTTP status code. A transfer that returns 200 but is declined for insufficient funds is technically correct and a business failure, and it should be distinguished from one declined because of a system error.

For each journey, define:

1. The steps: for a transfer, for example: start, validation, step-up authentication, execution, confirmation.
2. The outcome of each step: success, business decline (with a coded reason) or technical error.
3. The segmentation dimensions: channel, app version, operation type, destination bank, card brand, region. These are what make partial degradation visible.
4. The link to the technical trace: the business event must share the trace ID, so you can move from "what" to "why" in one click.

APM platforms such as Dynatrace or Datadog can capture part of this data through configuration, for example by extracting request attributes. But meaningful business outcomes (decline reason, journey step) usually require the application to emit them. It is the same principle that runs through all observability: an observable platform is not the same as an observable application.

Instrumentation example with OpenTelemetry

This Python snippet shows the idea: a trace span and a counter by outcome, with business attributes and no personal data.

from opentelemetry import trace, metrics

tracer = trace.get_tracer("banking.transfers")
meter = metrics.get_meter("banking.transfers")

# Counter of transfers by business outcome
transfers = meter.create_counter(
    "transfers.outcome",
    description="Transfers by channel, type and outcome",
)

def execute_transfer(request):
    with tracer.start_as_current_span("transfer.execute") as span:
        # Only low-cardinality attributes and no personal data:
        # never account number, name, ID document or exact amount
        attributes = {
            "channel": request.channel,           # "app", "web"
            "type": request.type,                 # "internal", "interbank"
        }
        result = process(request)                 # existing business logic
        attributes["outcome"] = result.code       # "ok", "declined_funds", "technical_error"
        span.set_attributes(attributes)
        transfers.add(1, attributes)
        return result

Business metrics next to technical metrics

The table offers a starting point for four common banking journeys. The metrics are indicative; each institution should adapt them to its products and channels.

Journey	Business metrics	Related technical signals	Useful dimensions
Login	Successful logins per minute, success ratio, drop-offs at the second factor	Identity service latency, second-factor provider errors	Channel, app version, authentication method
Transfers	Completed transfers per minute, declines by reason, time to confirmation	Core banking latency, queues to the payment network, integration errors	Type (internal or interbank), destination bank, channel
Card payments	Authorizations per minute, approval ratio, technical versus business declines	Authorizer latency, timeouts with the card network, fraud module errors	Brand, merchant type, card present or not present, region
Onboarding	Applications started and completed, drop-off by step, total time	Identity verification provider latency, document upload errors	Channel, journey step, provider

Putting both kinds of metrics on the same dashboard changes the conversation during an incident. The business sees how many operations are being lost, and the technical team sees in which component. Both talk about the same fact.

Detecting partial degradation before the call

Business metrics follow strong patterns by hour, day of the week and special dates (payroll days, month end, campaigns). That is why a fixed threshold such as "fewer than 100 transfers per minute" does not work: it is normal at 3 a.m. and alarming at noon.

These techniques work better:

• Ratios instead of volumes: the share of completed transfers over started ones is more stable than raw volume. If it drops, something broke, even when volume looks normal.
• Baseline comparison: compare with the same hour in previous weeks, or use the platform's anomaly detection, which learns seasonality.
• Segmentation: evaluate the ratio by dimension (destination bank, brand, version). A drop in a small segment disappears in the total and stands out in the breakdown.
• Separate business and technical declines: a rise in insufficient funds declines is business data; a rise in timeout declines is an incident.
• Service level objectives per journey: set an SLO on each journey's technical success ratio and alert on the error budget burn rate.

Synthetic tests complement this approach. A robot that logs in and checks a balance every few minutes, from several locations, catches problems during low-traffic hours, when real metrics have little data.

Privacy: no personal data in telemetry

Business observability brings telemetry closer to customer data, and that is where the risk lies. Logs, traces and metrics often have more access, more copies and fewer controls than the main database. They are also frequently sent to external platforms.

We recommend explicit rules:

• Nothing identifiable in attributes, metrics or logs: names, ID documents, account numbers, card numbers, emails, phone numbers, addresses.
• Amounts as ranges, not exact values, when the amount is needed for analysis.
• Pseudonyms only when needed for support, generated so they cannot be reversed from the observability platform, with restricted access to the mapping.
• Filtering at the source and in the collector: the OpenTelemetry Collector can remove or transform attributes before export. It is a second barrier, not the first.
• Defined retention and access for telemetry, as for any other data store.
• Instrumentation review as part of code review, with a list of prohibited fields.

In Spain, the General Data Protection Regulation (GDPR) sets out the principle of data minimization. In Latin America, each country has its own personal data protection law. For cards, the PCI DSS standard requires protecting cardholder data wherever it is stored, which includes logs and other telemetry stores. The exact scope in each case should be confirmed with the compliance and data protection teams.

How to start

1. Pick one journey with high volume and a clear business owner. Transfers or login are usually good candidates.
2. Map its steps and outcomes with business and development together, including the list of decline reasons.
3. Agree on dimensions and prohibited fields before writing code.
4. Instrument with OpenTelemetry or the APM platform's capabilities, linking every business event to its trace.
5. Build a shared dashboard with business metrics on top and technical metrics below.
6. Define the journey SLO and its alerts, and hand them to the command center.

Once one journey is working, the next one is easier: the event model, the privacy rules and the dashboard already exist.