Every payment system eventually builds a reconciliation operation.
It may be a small team with a spreadsheet, a nightly job that matches files, or an entire department armed with exception queues and carefully named CSV exports. The tooling varies; the underlying problem does not. A single economic event is captured independently by several systems, and somebody must later decide whether their records describe the same thing.
That is an expensive way to learn the truth.
A merchant has an order. A processor has an authorization. An acquirer has a clearing record. A bank has a movement. A wallet has an on-chain transfer. Each record is useful, each is locally correct, and none is automatically the other. Reconciliation is the work required to turn those separate claims into one operational fact.
The usual answer is more matching: stronger references, better files, more frequent imports, smarter exception handling. Those are worthwhile improvements, but they optimize the aftermath. They do not change the fact that the system started with multiple copies.
Counterpart begins somewhere else: make the relationship between a ledger entry and the thing outside the ledger explicit from the beginning.
Most jPOS-based applications are monitored using Elasticsearch, Kibana, and Grafana, or commercial alternatives such as Datadog, Splunk, and New Relic—and I never liked that.
External monitoring solutions usually rely on a Java agent that gives a remote server access to the JVM. These applications are often PCI certified because many QSAs don't fully understand what a JVM is or how powerful a javaagent can be. Otherwise, they would probably be considered uncertifiable or, at the very least, could extend the scope of your CDE to the remote provider. That's one of the reasons I wrote SensitiveStrings: to keep in-JVM sensitive data encrypted most of the time, adding a little defense-in-depth and flying under the radar of scripts looking for sensitive card data.
Elasticsearch is an awesome tool, but it's overkill to dump all your payload into it, such as verbose jPOS logs. We use it together with Debezium to store pointers to transaction data, not the transaction data itself, which would otherwise just replicate primary storage. Kibana is excellent for monitoring indexed business data, but log data is inherently unstructured. It evolves over time, and the queries evolve with it.
Grafana is also a great product, but dashboards are typically designed once, tweaked during development, and then left untouched for years. Eventually, a new DevOps team member inherits them without really knowing how they were built or how to modify them.
Those concerns led me to integrate metrics directly into jPOS using Micrometer, producing native Prometheus and OpenTelemetry metrics so we can eliminate remote Java agents altogether. I also worked on Structured Logging so logs are precise enough that you don't have to rely on regular expressions to search for information, and instrumented jPOS with Java Flight Recorder for the situations where we need to perform deep JVM forensics.
All those pieces are finally coming together in the integrated Metrics Explorer and Log Viewer. When you're investigating a problem, you can click on a graph and jump directly to the corresponding structured log messages with a single click. Instead of being limited to predefined dashboards, you have the full power of PromQL at your fingertips.
And then comes the final piece: integrated AI.
You can simply ask, "Please check if we have GC pressure over the last six hours," click the jPOS AI icon, and immediately have that free-text request translated into PromQL. No need to know the metric names, labels, or query syntax—the AI does that for you.
The goal isn't to replace Prometheus, Grafana, Elasticsearch, or Kibana. They remain fantastic tools. The goal is to make jPOS itself understand its own runtime well enough that the most common operational and forensic tasks can be performed from a single, integrated environment, without shipping logs and JVM internals to external systems by default.
Metrics are excellent at telling you that something changed. They are less good at explaining why.
That gap usually sends an operator across several tools: a dashboard for the symptom, a query editor to narrow it down, a log system for the events around it, and perhaps documentation to reconstruct the right query. The latest jPOS Control Plane demo brings those steps together without making the result opaque.
The Metrics Explorer works with the Prometheus metrics exposed by a running jPOS application. It lets an operator move from a chart to the relevant logs, ask questions in plain language, and inspect or run the generated PromQL before relying on it.
Operators should not have to discover that something went wrong.
A failed job, a locked account, or an error during a release is useful only if it reaches the person who can act on it. The new jPOS Control Plane notifications demo shows that path end to end: from an operational event, through routing and delivery, to the operator’s inbox and the channels the team already watches.
Reading a payment transaction is still expert work.
An authorization is not just an amount and a response code. It is the incoming ISO 8583 message, the authorization decision, the card and product state, the transaction chain around it, the ledger postings it produced, and the operational context that explains why it ended the way it did.
The new Transaction Log Inspector demo shows a practical way to make that expertise available on demand: explain a transaction in plain language, directly from the jPOS Control Plane, without turning the assistant into a side channel.
Payment systems are only as trustworthy as the testing behind them.
For an issuer, correctness is not just a response code. It is the ISO 8583 message on the wire, the product rules that shaped the decision, the ledger entries that were posted, and the evidence an operator can inspect later.
The new Client Simulator demo shows that loop end to end on the jPOS Control Plane: a live jCard issuer, a real CMF channel, a functional test suite, raw logs, and a reconciled general ledger.
Operational AI is useful only if it brings you closer to the evidence.
For logs, that evidence is not a paragraph of generated text. It is the indexed event, the timestamp, the realm, the host, the trace identifier, the original structured payload, and the surrounding events that explain what happened before and after.
That is the design point of the latest Log Viewer demo. Chat is now part of the operator workflow, but it is not a replacement for the Log Viewer. It is a faster way to ask the first question, keep context, and move toward the same structured evidence an operator would inspect manually.
Deploying financial infrastructure should not depend on someone remembering the right kubectl context, pasting the right kubeconfig into the right terminal, or manually reconstructing which Helm values were used last time. The deployment path is part of the control surface. It needs the same auditability, separation, and repeatability as the ledger itself.
The jPOS Control Plane brings Kubernetes deployment into the operator console. It stores target cluster credentials encrypted at rest, registers Helm charts from OCI registries, turns JSON Schema-backed chart values into typed forms, binds everything into reusable release plans, and drives dry-run, preflight, apply, resources, and logs from one audited UI.
Every ledger has a set of transactions it posts over and over. The accounts change, the amounts change, sometimes the counterparty changes—but the structure is always the same. A fee charge is always a debit to the customer account and a credit to fee income. A settlement is always the same four entries. A foreign exchange conversion follows the same arithmetic every time.
Freeform posting can handle all of these, but it puts the entire burden of correctness on the operator: right accounts, right sides, right layer, right formula—every time, by hand. Templates solve this. A template captures the invariant structure of a transaction and exposes only the parts that actually vary. Everything else is handled by the ledger.
Most ledger enforcement is hardcoded. If the business needs a new limit—a maximum account balance, a cap on transaction size, a rule that blocks weekend postings—someone files a ticket, a developer writes a check, the code ships in the next release. That cycle takes days or weeks, and the logic lives in application code rather than in the ledger where it belongs.
MGL solves this with Dynamic Rules. A dynamic rule is a CEL expression that the system evaluates on every posting, in real time, before the transaction is committed. If the expression returns false, the transaction is denied. No code change required. No deployment.
Most accounting systems that want to show derived figures—variance against budget, percentage execution, a consolidated multi-currency total—end up solving the problem the same way: periodic batch jobs that write synthetic entries to hold the computed values, or reporting scripts that reconstruct the computation at query time outside the ledger.
Both approaches have the same flaw. The derived figures live in a different place than the authoritative entries. They get stale. They diverge. Reconciling them back to source is always someone's problem.
MGL solves this with virtual layers. A virtual layer carries a formula instead of entries. Its balance is computed on the fly from physical layers—always derived from the same source of truth, always accurate to the query date, with no batch job required.
