An AI compliance checklist for banks in Pakistan

Every AI feature in a Pakistani bank clears the same gate: a review that wants to know where customer data is processed, what the provider keeps, who can produce evidence of both months later, and what currency the invoice is in. This is that checklist, written as the questions rather than the answers, because the questions are predictable and the answers are yours.

It is not legal advice, and it does not replace the institution's own compliance function or its regulator. It is the list that, answered in advance, turns a quarter of back-and-forth into one meeting.

Start with the question engineering never asks

A prompt is a data transfer. When an application puts a customer message, an account history, a CNIC number or a medical note into a prompt, that content leaves the country the moment the request does. That is not a computation on data the bank is holding. It is a transfer of that data to whoever operates the endpoint, followed by a computation there.

This is the framing most technical teams have never applied, and it is the one that decides the review. It does not matter that the payload is transient, or that the provider says it does not train on it. Under a localisation regime the transfer is the regulated event, and it happened.

Pakistan's data localisation rules, and what they mean for AI

One: classify what actually enters the prompt

Most of the review turns on this and most teams have not written it down. The same feature can be trivially approvable or a six-month problem depending on which fields reach the model, and the difference is often one join in a query nobody reviewed.

• Which fields are in the prompt today, including anything a retrieval step adds without being asked
• Which of those identify a person, directly or in combination with the rest of the payload
• Whether a system prompt, a few-shot example or a cached document carries customer content the feature does not obviously need
• What the model is allowed to return, and where that output is written afterwards
• Whether a redaction or tokenisation step exists, and whether anyone has tested that it holds under real inputs

Two: where is the request executed, and can you prove it

The claim to look for is not that a provider is local. It is that a provider can tell you, for one specific request, which country executed it, and can do so from a record rather than from a policy document. Those are different assurances and only the second survives an audit.

Ask whether location is selectable in the request itself. A gateway with both in-country and pass-through routes can answer per call, because the route is chosen by the model id. A provider that routes to whichever capacity is cheapest has deliberately made location not part of the interface, which is a reasonable design and the wrong one here.

Three: what is retained after the response

Retention and training are separate promises, and the first is the one that matters to a bank. A provider can truthfully say your data never trains a model while keeping prompts and completions for thirty days for abuse review, which is still a copy of customer data sitting on infrastructure the bank does not control and cannot inspect.

Get four specifics in writing: whether the content is stored at all after the response, for how long, who inside the provider can read it, and whether that changes by product tier. The answer differing by tier is common enough that assuming the public documentation applies to your account is a real risk.

What providers keep after the answer, and how to check

Four: who holds the key, and what can it do

A key with no ceiling, no expiry and access to everything is the finding an auditor writes up first, and it is the easiest one to close before they arrive. The question is not whether the bank has a policy about it. It is whether the limits are enforced by the platform or by the good intentions of whoever last used the key.

• Can a key be capped in money, so a loop is a rejected request rather than an emptied balance?
• Can a key be restricted to specific models, so a cheap internal tool cannot reach an expensive route?
• Can a key expire on a date, so a contractor's access ends without anyone remembering to end it?
• Is the raw key shown once and stored hashed, or is it retrievable by anyone with dashboard access?
• Is issuing, editing and revoking a key written to an audit log with an actor and a timestamp?

Five: can you reconstruct a request months later

The review will ask what evidence exists after the fact. The useful answer is a per-request record that names the model, the key, the project, the status, the timings, the token counts and the settled cost, held by the bank rather than obtainable only by opening a support ticket with a vendor.

Note what is not in that list. A log that keeps the prompt is a second copy of the customer data, in a system with different access controls than the one it came from. The strongest position is a record complete enough to answer an audit and empty of anything a customer said.

Six: what the invoice says

This part is not usually thought of as compliance and it stops as many projects. A dollar-denominated bill against an international card means a foreign payment rail in the critical path of a production system, a balance held in a currency the bank does not earn in, and a variance line that reappears every month.

Billing in rupees from prepaid credits removes all three. It also changes the cap from a card that may be declined at an unpredictable moment into a limit the platform enforces with a rejected request, which is a much easier control to describe in a document.

How P/9 answers each of these

Stated plainly, so the list can be checked rather than trusted.

• Location: the PK NPU-native pool is served on Huawei Ascend hardware P/9 operates inside Pakistan, and the route chosen in the model id determines the pool
• Retention: no prompt and no completion is retained on any route; the request log keeps the model, key, project, status, timings, token counts and settled cost
• Keys: capped in rupees, limited to a rate, scoped to specific models and expirable, all enforced by the gateway; the raw key is returned once and stored hashed
• Evidence: request logs and analytics in the dashboard, plus an audit log of key creation, edits and revocation
• Invoice: Pakistani rupees, prepaid, at a rate published per million tokens for every route in the catalogue

How the PK Endpoint is built, and what runs on it

The short version

The technical work in a bank's AI feature is rarely what delays it. The delay is a set of questions nobody collected in advance, most of which have a one-line answer if the provider was chosen with them in mind and no answer at all if it was not.

Answer the six above before the review rather than during it, and the review becomes a formality instead of a quarter.