Cloud and security · Banking
Observability and SRE for transaction systems
We build observability and SRE for transaction systems in banks and payment firms, applying site reliability engineering practice: service level objectives tied to business outcomes, end-to-end tracing of a payment across systems, business metrics next to technical ones, synthetic transactions, alerts that point at symptoms, and incident response and release practices that protect availability. Operations see problems before customers do, and you own the tooling and the runbooks.
Checklist · Payments
Payment hub and ISO 20022 readiness checklist
A checklist for banks and payment firms planning a payment hub, a real-time payments connection or an ISO 20022 migration: formats, mapping, validation, routing, exceptions, reconciliation and resilience.- 01Eight areas to review before you choose or build a payment platform.
- 02The message and data points that cause rejections: addresses, identifiers and remittance data.
- 03Questions on cut-offs, liquidity and exception handling.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Service level indicators and objectives
Measures of what users experience, such as payment success rate, latency and availability, with objectives and error budgets agreed between business and engineering. - 02
Distributed tracing
A trace of each transaction across channels, hub, core and external networks, so the time and failures at each step are visible. - 03
Metrics and logs
Consistent technical metrics and structured logs, enriched with business context such as rail, client segment and product, with controls on sensitive data. - 04
Business transaction monitoring
Live views of volumes, values, success rates and queue depths by flow, with baselines that adapt to time of day and calendar effects. - 05
Synthetic transactions
Automated test transactions that exercise key journeys continuously from outside, to detect failures before real customers meet them. - 06
Alerting and on-call
Alerts based on symptoms and error budget burn rather than every cause, routed to on-call engineers with runbooks and escalation paths. - 07
Incident response and post-incident review
Defined roles, communication, timelines and blameless reviews that produce tracked improvements, linked to the regulatory incident process. - 08
Capacity and performance engineering
Load tests, capacity models and performance budgets for peak days, with results used in release and scaling decisions. - 09
Release safety and resilience testing
Canary releases, feature flags, automated rollback and controlled fault injection to learn how the system fails before it does so in production.
Reference architecture.
Standards and interfaces
What we design against.
- OpenTelemetry
- The open standard and tooling for traces, metrics and logs, avoiding lock-in to one monitoring vendor.
- SRE practice
- Service level objectives, error budgets, toil reduction and blameless post-incident reviews as set out in site reliability engineering practice.
- Incident reporting requirements
- Regulatory rules on classification and reporting of operational and ICT incidents, which the incident workflow feeds.
- ISO 22301 and operational resilience
- Continuity and resilience frameworks that tie service objectives to impact tolerances.
- Data protection and logging standards
- Rules on personal and payment data in logs and traces, including masking and retention.
- DORA and release metrics
- Delivery performance measures such as deployment frequency, lead time, change failure rate and recovery time.
Data model
The core entities.
- Service and SLO
- Service, owner, indicators, objective, window and error budget.
- Trace and span
- Transaction identifier, steps, durations, status and attributes.
- Metric series
- Name, labels, value, time and the system or flow it describes.
- Synthetic check
- Journey, schedule, location, result and latency.
- Alert and page
- Rule, severity, recipient, acknowledgement and resolution.
- Incident and review
- Timeline, impact, causes, actions, owners and closure.
- Capacity model
- Load profile, capacity measured, headroom and planned scaling.
When custom development is the right call.
Controls designed in, not added later.
No sensitive data in telemetry
Card numbers, personal data and secrets are masked or excluded from logs and traces at the source.Access to observability data
Telemetry is access-controlled by team and sensitivity, with audit of who looked at what.Tamper-resistant logs
Security-relevant logs are written to protected storage and retained for the required period.Safe fault injection
Resilience experiments run under agreed rules, with safeguards, approval and the ability to stop immediately.Change control for alerts and SLOs
Changes to objectives and alert rules are reviewed, so signals are not silently weakened.
From discovery to a system you run.
- 01
Journeys and objectives
We pick the most important customer and payment journeys with the business, and define what good looks like for each. - 02
Instrumentation and baseline
Tracing, metrics and logs are added to the systems on those journeys, and a baseline of current performance is established. - 03
SLOs, synthetic checks and alerting
Service objectives, synthetic transactions and symptom-based alerts replace noisy cause-based alerts. - 04
Incident and release practice
On-call, incident roles, reviews, canary releases and rollback are introduced and practised. - 05
Capacity and resilience testing
Load tests and controlled fault injection show how the system behaves under peak and failure, and the findings are fixed.
Relevant work
Where to see our work.
Common questions.
- What is the difference between monitoring and observability?
- Monitoring checks known conditions against thresholds. Observability lets you ask new questions of a running system from its traces, metrics and logs, which matters when a failure has not been seen before.
- How do you set a service level objective for a payment system?
- From what the customer experiences, such as the share of payments completed successfully within an agreed time, agreed between business and engineering, with an error budget that guides how much change risk is acceptable.
- Can we trace a payment across systems from different vendors?
- Yes, by propagating a transaction identifier through channels, hub, core and gateways and using standard tracing. Where a vendor system cannot emit traces, logs and message identifiers fill the gap.
- How do you keep sensitive data out of telemetry?
- By masking or excluding it at the source, validating logs for leakage in the pipeline and restricting access to what remains.
- Who owns the dashboards, alerts and runbooks?
- You do. The configuration, the runbooks and the data stay yours.