One instant transfer in ten fails between 2:00 and 2:20 pm, and nobody finds out until a customer calls. The technical dashboards are green: services answer, CPU is calm. That gap is what business observability financial services programmes close, by tying system behaviour to what the customer experiences, payment by payment. On 14 October 2026 Dynatrace published a post on the topic describing a European investment bank. What follows is an SRE practitioner’s reading, with my own examples.
I start from one operational decision: what must you measure to know, within five minutes, that part of your payments is degrading? Everything here targets Dynatrace SaaS with Grail. I have not run these examples on a live tenant: the payload and query are templates to adapt, and I flag what I could not verify.
Business observability financial services: why it matters
In a financial institution a silent incident is expensive: duplicated transactions, missing validation steps, decisions made on incomplete data. They tend to surface late, through a complaint, a failed settlement or a regulator’s question. The vendor’s post stresses this point.
Business observability means carrying business data (amount, channel, transfer type, outcome) into the same platform as traces and logs. You stop keeping two versions of the truth, the engineer’s and the business owner’s. For the basics of the events themselves, see our business events tutorial; this piece takes a sector angle.
Decision 1: pick the events of one payment journey
Do not try to capture everything. Take one journey, say a transfer, and list its states with the business: initiated, screened, accepted, settled, rejected. Each useful transition becomes a business event. A one-hour workshop with a product owner is enough, and it is the most rewarding part; the vendor also describes this business and IT alignment as the starting point.
Keep names stable. An event.type such as payment.completed and one event.provider per emitting system let you filter cleanly, even when three teams feed the same table.
Decision 2: how the data gets in
The documentation lists several sources: OneAgent capture rules on HTTP requests, web and mobile RUM, the REST API, extraction from logs or spans through OpenPipeline, and a workflow action. The post mentions a case where OneAgent reads fields from HTTP payloads without code changes, with a Kafka Sink Connector as fallback. I could not verify that connector in the documentation, so I do not recommend it here.
- OneAgent: handy when you do not own the application code, limited to HTTP requests.
- API: suits third-party systems and batch jobs. The endpoint is
/api/v2/bizevents/ingest; the maximum request size is 5 MB. - OpenPipeline: useful to transform or enrich what already sits in logs.
With plain JSON through the API, no field is mandatory according to the documentation I read. With CloudEvents, specversion, id, source and type are required; source becomes event.provider and type becomes event.type. On tokens, the pages I read name the bizevents.ingest scope for a classic token and openpipeline:bizevents:ingest for a platform token; the SDK page names a third one, so check the exact scope on your tenant.
A realistic payment event
This is the template I start from. Amounts and identifiers are made up.
Mind personal data: send neither full IBANs nor customer names. A payment identifier is enough to join the event to everything else. If sensitive fields arrive anyway, mask them at ingestion, as in our article on masking with OpenPipeline. Grail converts nested objects to strings, so flatten your fields before sending.
Respect the time window too: a timestamp more than ten minutes in the future or more than 24 hours in the past gets the event dropped. Do not count on the API to replay an old batch.
Decision 3: turn events into a business SLO
A business SLO answers a question like « 99.5% of instant transfers settle in under ten seconds ». This DQL query returns the success rate and latency per channel.
Read it like this: filter one event type, aggregate by channel, then derive the rate. If mobile drops to 92% while web stays at 99.9%, you have located the problem without opening a single trace. Such a calculation then feeds an objective, as in the module on SLOs in Dynatrace SaaS. I did not verify how to build an SLO directly on the bizevents table: test it in your own environment.
How to check that it works
- Send a test event through the API with a recognisable
event.provider(test.team-x). - Run
fetch bizevents | filter event.provider == "test.team-x"over the last few minutes: the row should appear. - Compare the event count with your payment database counter over one hour: a gap above a few percent points to a capture rule that is too narrow.
- Deliberately stop emission for two minutes on a test environment and confirm that your volume-drop alert fires.
Good practice
- One journey at a time, agreed with the business, before widening.
- Few fields, all documented: identifier, channel, amount, status, duration.
- No raw personal data; mask at ingestion.
- Alert on volume drops as much as on error rates: a payment that never arrives raises no error.
- Keep Managed and SaaS apart: this article applies to SaaS with Grail only; for the differences, see Grail versus Classic.
Frequently asked questions
Does business observability replace compliance tooling?
No. The vendor’s post speaks of operational evidence that may help with DORA, PSD2 or GDPR, depending on the requirements that apply. It is support; compliance remains a matter for your legal team.
Do I have to change the payment applications’ code?
Not necessarily: a OneAgent rule reads HTTP requests without touching code. For a system without HTTP, use the API or OpenPipeline.
How does this differ from the business events article?
The first tutorial follows one order KPI step by step. This one starts from a sector, finance, and its decisions: journey, privacy, business SLO.
Conclusion
Pick one payment journey, define its states with the business, ingest a few clean fields, then measure a success rate per channel. Start on a test environment and keep the unverified points above in mind before production.
span.observer is an independent community blog, not affiliated with Dynatrace LLC. Brands mentioned belong to their owners. Tools change quickly: check commands and options in the official documentation.
Originally published on span.observer. French version: https://span.observer/fr/business-observability-services-financiers/.
Top comments (0)