Shrinking the part of
the estate that has to be audited

MoneyChain had grown the way successful payments companies do: quickly, in one account, with card data flowing wherever it was convenient. By the time we were called in, the compliance boundary had expanded to cover most of the estate, and the practical effect was that shipping anything required a conversation about scope.

The situation

Card data touched the transaction service, the settlement batch, the reporting pipeline, the support tooling and — as we discovered during scoping — the application logs. Each of those pulled its dependencies into scope with it. The cardholder data environment was not a boundary so much as a shading of most of the architecture diagram.

Separately, fraud signals came from an overnight batch. For a card-present-adjacent flow that is a long time to be wrong, and the operations team had built a manual morning review process to compensate.

• Compliance boundary covering the large majority of the estate
• Assessment preparation consuming senior engineering time each cycle
• Fraud detection running on a nightly cycle with manual review
• No per-transaction view of infrastructure cost as volume grew

What we did

Tokenise at the edge

Card data is captured and exchanged for a token at the earliest possible point, and only the tokenisation service and its store ever see a primary account number. Everything downstream — settlement, reporting, support tooling, analytics — works with tokens and never enters scope.

Put the boundary in the account structure

The cardholder data environment moved into its own AWS account with its own network, its own pipeline and Service Control Policies that prevent data leaving it. An account boundary is something an assessor can see and a developer cannot accidentally cross; a security group rule is neither.

Stream what used to be batch

Transaction events into Amazon MSK, with scoring on the stream and a decision returned within the authorisation window. The manual morning review still exists, but as an exception queue rather than the primary control.

Cost per transaction

Infrastructure cost attributed per transaction and per product, so platform investment could be argued in the same terms as interchange and scheme fees rather than as an IT line item.

Scope figures are counted as systems within the assessed boundary, not as a proportion of spend.

The hard part

Scoping found full primary account numbers in application logs from a legacy settlement service. Not in a database, not in a message — in log lines, retained for months, replicated into the log aggregation platform and therefore into its own dependency chain.

That discovery reordered the entire program. Everything else paused while the logging was fixed, the historical logs were purged under a documented process, and the incident was handled through MoneyChain's own obligations rather than quietly. It cost roughly six weeks and it was not optional.

Every PCI scoping exercise we have run has found card data somewhere nobody expected. The question is only whether you find it or an assessor does.

The second difficulty was more ordinary. Tokenisation changes the shape of every downstream query that used to join on a card number, and several reporting outputs had to be redesigned rather than migrated. We sequenced those alongside the migration instead of treating them as a follow-up, which is why the reporting team did not lose a quarter.

Where it landed

The assessed boundary now covers the tokenisation service and its store rather than most of the platform. Assessment preparation is largely generated from AWS Config and pipeline state instead of assembled by hand, and the fraud signal arrives inside the authorisation window rather than the following morning.

Cost per transaction fell as a side effect rather than a goal: pulling systems out of scope also pulled them out of the more expensive controls that scope required.