On-premise observability for banking and financial services

Wrentrix is designed with banks in mind, among other regulated organisations. That is a statement about design goals. It is not a customer list, and nothing here describes any particular bank.

What makes a bank's system different to observe

Tracing a shop's checkout and tracing a money transfer use the same technology. The surroundings are different.

The path is long and mixed. A mobile transfer might go from the app to a gateway, an API layer, a fraud check, a limits service, the core banking system, a payment network connector, and a notification service. Some of those are modern containers. Some are decades old. Observability that stops at the Kubernetes boundary shows you a span called "core banking call, 4 seconds" and nothing beyond it.

The traffic follows the calendar. Salary days, month-end, the end of the tax period, and the daily close all produce patterns that don't look like a normal week.

Change is controlled. Production changes go through approvals, freeze periods and separation of duties. A tool that needs its own weekly production change, or a "just add this agent and restart everything" step, runs into that process immediately.

Data sensitivity is high. Account numbers, national ID numbers, card data and balances can all appear in logs and traces if nobody has checked.

A worked incident: slow transfers on a salary day

The following is invented, to show how the parts work together.

At 09:20 on a salary day, the transfer SLO starts burning at a rate well above normal. Fast-pair burn-rate alerts page the on-call engineer. On a day like this, traffic is always high, so the first question is whether this is just load.

1. The grouping puts the alerts on the mobile gateway, the API layer and the limits service into one problem, using the live dependency map, instead of three teams being paged about three things.
2. Traces show time accumulating in the limits service. Its calls to the database look short, but the server span is long, with a large gap before the database call.
3. Method data shows the wait is on acquiring a database connection, with that method far outside its baseline, whereas query execution is normal. The queries are fine. They just can't get a connection. If that pattern is new to you, see connection pool exhaustion.
4. Change correlation shows that a ConfigMap edit a week earlier lowered the pool size. It went unnoticed until this morning because normal load never reached the new limit. A pod restart last night is what activated the change.
5. Remediation runs as an approved Ansible AWX job, applying a previously reviewed change. The approver sees the evidence. The audit log records who approved what, and AWX records the job.
6. The short burn-rate window clears a few minutes later, and the alert closes itself.

The interesting point is step 4. A change made a week ago, inert until load and a restart lined up, is hard to find by memory. A timeline makes it possible. Reducing MTTR covers how to measure whether you are getting faster at this over time.

Calendars and baselines

Hour-of-week baselines capture the weekly rhythm: Monday morning differs from Sunday night. They aren't calendar-aware in the way a bank's traffic is. Think through these cases:

• Salary days fall on particular dates, and thus move across the week. An hour-of-week slot only sees them on occasion, so expect anomaly flags on those days. Your SLOs still give an accurate reading, because they don't depend on what's normal.
• Month-end and quarter-end batch runs look unusual to a weekly model. Note them in your on-call handover.
• Public holidays, especially moving ones, produce abnormal lows. A low-traffic anomaly on such a day isn't a fault.
• The daily close usually falls in the same weekly slots, so baselines handle it well.

The right response isn't to distrust the system. Use the two kinds of signal together, page on burn rate, and treat anomaly flags on known calendar days as context.

Fitting into the change process

Each of the following is a property you can verify, and each is relevant to the question a change board will ask.

That approval mode deserves particular thought. Many banks will start with remediation in approval mode for anything that alters production, and only allow automatic actions that fall within a pre-approved standard-change category, if at all. Align this with your own change management policy, and have someone from risk or audit look at the design early.

Regulation, in general terms

Not legal advice, and details vary by jurisdiction and institution. Check with your compliance function. We do not claim that Wrentrix holds any certification or makes an institution compliant.

• BDDK (Türkiye). Rules on banks' information systems address, among other things, where primary and secondary systems reside, outsourcing and audit trails. A monitoring system that holds customer-related data raises questions under those headings. Whether it counts as a primary system or as outsourcing is a judgment for your institution.
• DORA (EU). Applying since January 2025, it sets expectations for ICT risk management, incident classification and reporting, resilience testing and oversight of ICT third-party risk. Detection and diagnosis capability feeds directly into the incident reporting work, and a self-hosted tool changes the nature of the third-party discussion, though software suppliers remain a topic.
• PCI DSS. Cardholder data must be protected and must not be stored unless needed, and sensitive authentication data has strict limits. Logging and monitoring of systems in scope are requirements as well. If your traces or logs capture card data, your monitoring platform may come into scope. Keep the data out, and decide with your assessor how to treat the platform.
• KVKK and GDPR. Personal data rules apply to telemetry. See the data residency page for how to find and reduce it.

Mapping onto network zones

Banks tend to have strict segmentation: DMZ, application tier, database tier, and core systems. The standard design question is what crosses what.

• Use collectors per zone, so each cross-zone flow is one documented path to one endpoint, on one port. Your firewall team will appreciate having fewer flows to review. See the collector guide.
• Agents and hosts in each zone report inward to the installation, not out to the internet. 0 bytes of telemetry leave the network, and air-gapped operation is supported for zones without any route out.
• RUM for internet banking needs an inbound path from customer browsers to a collector. That's a new public-facing endpoint, and your security team will want it reviewed, along with what the collector captures. Customer session data needs extra thought.
• Probes check the routes that matter. A TCP probe from the application zone to a payment connector catches a removed firewall rule. TLS expiry alerts catch the mutual TLS certificates on partner links, which are a frequent source of avoidable incidents.

Where the visibility ends

Be realistic about these limits, and raise them early in any evaluation.

• Mainframes and older core systems. If a platform can't run an OpenTelemetry SDK, you still see the call from the caller's side: duration, errors and which requests were affected. Inside the core itself you will rely on its own tools. Ask us about your specific platforms.
• Other operating systems. Linux is what's described for host monitoring. Ask about anything else.
• Proprietary middleware. Tracing through it depends on whether context can pass through. If it can't, a trace stops there.
• Payment networks and partners. You will see your side of the call, and that's it. That is still useful for showing that the delay isn't on your side.
• Scale. We do not publish benchmark figures. Test with your own traffic shape, and include peak days in the test.

A note on AI: the local model keeps inference on your hardware, which avoids sending financial telemetry to any outside service. Your model risk function may still want to review its use, particularly if it's connected to automated action. AI can also be switched off entirely.

Frequently asked questions

Can APM trace transactions through a core banking system?

It can trace up to and out of the core wherever context is passed and instrumentation exists. If the core can't be instrumented, you still see the call duration and errors from the calling service. Whether more is possible depends on the platform, so ask us about yours.

Does Wrentrix need to send bank data to the cloud?

No. It runs on your own infrastructure with 0 bytes of telemetry leaving the network, and AI runs on a local model. It also works fully air-gapped, without license calls.

Is Wrentrix certified for banking regulation?

We make no such claim on this page. Regulations such as BDDK rules, DORA and PCI DSS apply to your institution and its processes, so a tool can support your approach, but it can't make you compliant. For security questionnaires, write to info@wrentrix.com.

Does installing the agent count as a production change that restarts services?

Installing it is a change your process should review, but Wrentrix doesn't restart workloads. Instrumentation arrives as pods restart through your normal releases. If the agent is unavailable, the admission webhook fails open and pods start normally.

Can automated remediation satisfy separation of duties?

It can be arranged to support that. Approval mode requires a person to authorise an action, and the audit log and AWX job history both record what happened. Whether that design meets your policy is for your risk and audit functions to decide.