The same service that settles a payment reads the customer record, the ledger row, the card token, and the bank credential to do it. Move the money, move the data. They are one path, called by the same services, holding the same access.
Security teams underweight that. Your most valuable data does not leave on a break-in. It leaves on access you granted on purpose, to the services that need it to do their jobs. Every move is permitted. The pattern is the breach.
Where fintech security spends its budget
The stack a fintech buys is built around permission and perimeter. IAM decides who can call what. A WAF and API gateway police the edges. Tokenization and a vault keep card numbers out of plaintext. SOC 2 and PCI DSS prove the boundaries are drawn and audited.
These matter. They stop the unauthorized actor, the unencrypted store, the open bucket. A fintech without them does not get to operate.
But every one of those controls answers one question: was this action allowed? They answer it well. The risk they were never built to see is the one where the answer is always yes.
The move that is always permitted
Walk a payments flow. A reconciliation service reads the ledger, joins a customer table, calls a banking partner, writes back a settlement. A support tool pulls account history to close a ticket. An analytics job exports a transaction slice to a warehouse. An engineer reruns a backfill against production after a migration fails.
Someone granted each of those on purpose. Each runs through a service account or credential that is supposed to touch that data. IAM says yes, because it is supposed to. The gateway sees a normal authenticated call. PCI scope holds because nobody pulled raw PANs.
Change one variable. The reconciliation service starts reading customer records far outside the batch it needs to settle. The support tool pulls full account history for accounts with no open ticket, in volume, at three in the morning. The backfill credential, which legitimately touches production, starts moving ledger and customer data toward a destination it has never written to.
No policy breaks. No alert fires. The access was real. Only the pattern changed.
This is the center of the business, not an edge case
A compromised partner integration. An over-scoped service account. A contractor with legitimate access. An internal tool reused for something it was not built for. Each moves data through a channel that is supposed to carry it. The credential is valid. The destination is reachable. The volume is the only tell, and it accrues slowly enough that no threshold trips.
Predictive tools guess these in advance and bury the team in false alarms while the normal-looking move walks past them. Forensics reconstruct it after the data is gone, in the disclosure letter to the regulator. Neither watches the pattern form.
You see it in one place: at runtime, while the data moves. Not before. Not after. As it happens.
What Hilt resolves on the wire
Hilt watches data movement at the kernel, metadata only by default, off the path. It does not sit inline. It does not block, drop, or alter traffic. It does not read your data to know a pattern is wrong. The collector runs single-tenant inside your own cloud at roughly 0.1% of one core and 4 to 8 MB of memory per host, so it sits beside a latency-sensitive payments service without standing in the path of a transaction.
Hilt resolves each move to a probabilistic, source-dependent identity: which service, which job behind it, which destination, and whether the move fits what that identity normally does. A control that logs an authenticated call cannot tell you that. The reconciliation service has a shape. The support tool has a shape. The backfill credential has a shape. When a shape changes, the deviation surfaces across layers at once.
Take the support tool reading at three in the morning. The job is unusual for that identity. The access is a bulk read of high-value customer paths in a tight window. The destination volume is unusual for that channel. Any one signal is noise. Together they are a pattern, and a pattern is a case, not an alert. Hilt writes the case, with the identity, the job, and the movement that does not fit, and isolates the host at the network from the control plane, never filtering its packets.
How this sits with what you already run
Hilt does not replace the controls a fintech runs, and it should not try.
IAM still decides who can call what. Tokenization still keeps card numbers out of plaintext. Your gateway and WAF still police the edges. SOC 2 and PCI still prove the boundaries are drawn. That is permission and perimeter, and it is good at its job.
Hilt covers the layer none of them touch: the behavior of permitted data movement across the moves themselves. It assumes the access was granted on purpose, then watches what that access does, resolved to the job behind it and scored against how that data normally moves. The path from kernel event to written case runs single-tenant inside your own account, AWS, GCP, Azure, or Ali Cloud. Events never leave it, which is the answer your residency reviewer wants on regulated money movement.
A fintech security leader can already answer who is allowed to touch ledger and customer data. The controls enforce it. The harder question is what that allowed access did last night, resolved to the service behind it and scored against how that data normally moves.
If your stack proves every move was permitted but cannot tell you the pattern across them was wrong, that is the blind spot. It is exactly where money-movement data leaves.
Want to see it against your own data path? Book a 30-minute call, engineer to engineer, and we will walk through where the collector sits and what it resolves in your environment.