What technology teams misunderstand about authorisation

An authorisation file describes the business model, the governance, the risk framework, the safeguarding arrangement, the control plan, the outsourcing, the continuity arrangements and the systems. Much of it is written by people who are not going to build it, at a moment when the system does not exist yet.

Every commitment in that file becomes a requirement. If the file says reconciliation is performed daily, then reconciliation is performed daily, and the absence of a run on a bank holiday is a finding. If it says four eyes are applied to a category of change, the system has to enforce and record four eyes.

The correction is procedural and cheap: engineering reads the file before it is submitted, and flags every sentence that describes system behaviour. Each of those sentences is a ticket.

Supervision is proportionate to size, complexity and risk. A small institution is not expected to have the control apparatus of a large bank. This is genuinely helpful and it is routinely misread as permission to defer.

Proportionality changes the depth of a control, not its existence. A monitoring function may be one person rather than a department, but the function exists, has a mandate, and produces records. The scaling applies to how much, not to whether.

Most of the interesting parts of a modern payment stack are provided by someone else: card processing, accounts at a partner institution, identity verification, screening, cloud infrastructure. Using them is normal and expected. Believing they carry the obligation is the mistake.

The institution remains responsible for the outcome, which has a concrete engineering consequence: you need your own view of what the provider did. Their dashboard is their record, not yours. If a screening provider returns a decision, store the request, the response, the version of their list or model where they expose it, and the time. If they change something silently and results shift, you want to be able to see the shift in your own data rather than learn about it from a supervisor.

The same applies to exit. An arrangement you cannot leave inside a reasonable period is a concentration you have to be able to describe and justify.

Institutions rarely fail supervision because a control was absent from the start. They fail because the business changed and the control did not. A new payment corridor, a new customer segment, a new product built quickly for a partner: each one arrives with a population the existing rules were never written for.

The defence is a habit rather than a technology. Any change to what the institution sells, to whom, or through which provider, triggers a review of which rules apply to the new population and whether their queries actually include it. Doing that review as part of launch is cheap. Doing it after an inspection is a remediation programme.

Supervision is periodic, documentary and specific, and rarely adversarial. Most exchanges are requests for information. A well-instrumented institution answers them by running a query. A poorly instrumented one assembles a team for two weeks.

That difference in cost is decided years earlier, by whether the daily series exists, whether controls store their populations, and whether rules carry versions. None of that is visible in a product roadmap, which is exactly why it needs a sponsor who understands what it buys.

Authorisation is best understood as agreement on what you said you would do, rather than permission to begin. Engineering that reads the file as a specification, and builds the evidence-producing version of every claim in it, arrives at the first inspection with answers instead of a project.