Regulated data arrives inside the prompt
A question to your support assistant carries a national ID, a credit flow sees an IBAN, fraud analysis looks at a card number. That data is inside the prompt — not in your application code. Embed compliance in code and every change in regulatory interpretation becomes a release.
- National IDs, IBANs and card patterns detected with validation
- Fallback is disabled while a residency rule is in force
- The decision trace keeps the rules that matched and lost
0requests leaving the region while a residency rule is in force
What is hard in this sector
The shared problem for teams using LLMs in financial services is where the decision is made. Once model selection, redaction and refusal logic is spread through application code, two things break together: changing a rule gets slow, and the question an auditor asks — why did this answer come out this way — has no single answer.
What is hard in this sector
- When a regulatory interpretation changes, the rule change enters the release pipeline — typically two weeks.
- Developers are not privacy specialists; redaction logic gets written wrong in good faith.
- The audit trail keeps the model name and the rule name, but not the instruction text that produced the answer.
- Provider keys sit with the team; rotation and leak exposure are engineering overhead.
- With no safe way to try a new model, migrations keep being deferred.
The first three rules you'd write
These are not illustrative examples; they are the rules we discuss in the first session in this sector. Each is authored as YAML in the console, measured in shadow mode, then enforced.
- 1
national-id-pin-resident- When
- signals.pii.types contains a national identity number
- Then
- pin to a model in the local region · mask the prompt · switch the cache off · disable the fallback chain
Why it is shaped this wayOn a compliance path, failover is a vulnerability. Leave fallback on and the moment the first candidate goes down the request quietly moves to another region — exactly what you were preventing. With no candidate left, the gateway returns an error. - 2
card-data-deny- When
- signals.pii.types contains credit_card
- Then
- refuse the request · 403 · write an audit tag · notify the compliance team
Why it is shaped this wayRefusing rather than masking and continuing is the cleanest way to keep the system out of PCI scope. Masking is a processing activity; refusal is not. - 3
credit-decision-audit- When
- request.headers.dataClass = credit_decision
- Then
- pin the prompt version · retain the conversation log · audit tag · exclude from canary
Why it is shaped this wayIn a flow that affects a credit decision, which instruction text ran is the first question an audit asks. Canary must be off here — evaluating the same kind of application against two different prompt versions is not defensible.
What you show in an audit
- Decision trace
- The winning rule, the rules that matched and lost, the obligations enforced, the model and region selected
- Prompt traceability
- The identity and version of the prompt that produced the answer
- Residency evidence
- Which region processed the request, and why the foreign candidate was dropped
- Redaction evidence
- Which data types were masked; that unmasked content never reached a provider
- Change history
- Which version of the rule set was in force, and when
- Key custody
- Provider credentials are not yours; rotation and leak surface are outside your scope
Questions from this sector
When a redaction obligation applies, what reaches the provider is the masked text — [TCKN_TR] in place of the identifier. And if you wrote a residency rule, the request never falls to a foreign candidate in the first place. The two work together: redaction bounds the content, residency bounds the geography.
No. The scanner applies the checksum, so an order number or a random figure produces no signal. That matters: a scanner that treats every eleven-digit number as PII over-constrains production traffic, and the team ends up switching the rule off.
A signal carries not only detected but available. If the scan could not run, policy sees that and can choose to be conservative. "No PII was detected" and "PII could not be scanned for" are different statements — a rule that mistakes a missing signal for a clean prompt is the most expensive error an audit can find.
Modelion makes no certification claim. What it does is make your compliance obligation writable as policy and auditable: move the decision to one place, and produce the evidence automatically. The scope itself remains yours and your legal team's responsibility.
The regulatory references on this page exist to explain which product behaviour they drive; they are not legal advice. The scope of your own compliance obligations is something to establish with your legal team.
Let's start with your own rule set
The first session covers your traffic and your regulatory boundaries; you leave with a divergence report measured in shadow mode and three rules ready to write.