Customer secrets masked, money movement approved by a person.
In banks, agents pay card debt, prepare credit files, write call-centre notes and answer complaints. BDDK’s Information Systems Regulation requires data to stay in the country (Art. 25) and an audit trail (Art. 13). Banking Law Art. 73 protects customer secrecy. Thulpar runs in front of the model as an OpenAI-compatible gateway. TCKN and IBAN values are found by checksum and masked, a transfer above the threshold waits for four-eyes approval, and every decision is reported in the BDDK evidence pack.
tr-banking-bddk
On-premise, Standard or Performance tier. The tr-banking-bddk template. The kvkk and bddk evidence profiles.
- BDDK Information Systems Regulation Art. 13, 25, 27
- Banking Law Art. 73 (customer secrecy)
- KVKK 6698 Art. 6, 9, 12
- DORA Art. 9, 17–20 (for EU subsidiaries)
The locality requirement
Cloud guardrail APIs carry prompts and answers abroad. That conflicts with Art. 25.
Watch the runs →The scenarios below are derived from the product’s real rules.
Every scenario is an agent run written to the product’s real rules. It shows the stage, the rails, the decision, the finding, the approval and the ledger entry step by step.
3 scenarios →What comes up in practice
The locality requirement
Cloud guardrail APIs carry prompts and answers abroad. That conflicts with Art. 25.
Approval on money movement
A payment an agent starts must wait for a person. That approval belongs in the infrastructure layer, where application code cannot skip it.
Audit-ready evidence
The auditor asks which policy version, which detector and which decision applied. The answer has to be a signed evidence pack.
3 scenarios
The player opens on the flagship scenario. Pick the others below.
A customer pays card debt from the mobile channel; the IBAN is masked and a transfer above the threshold passes four-eyes approval.
7 GR-*
| id | control | OWASP | rails |
|---|---|---|---|
| GR-PII-01 | PII and special-category detection + masking (TCKN, IBAN, phone, health) on input/tool/output/log | LLM02 / — / MCP10 | pii.detect, pii.redact, file.metadata_pii |
| GR-TOOL-02 | Durable human approval on high-impact actions, four eyes | LLM06 / ASI02, ASI09 | labels.sink |
| GR-TOOL-01 | Tool-call privilege policy (default deny) | LLM06 / ASI02, ASI03 / MCP02 | tool.authz, tool.args |
| GR-LOG-01 | Tamper-evident event log (model/tool/policy/approval/hit), ≥ 6 months, auditor export | — / — / MCP08 | |
| GR-INJ-02 | Indirect injection from tool/RAG output: untrusted label, no new tool call without policy | LLM01, LLM08 / ASI01, ASI06 / MCP06, MCP10 | injection.indirect, file.hidden_text |
| GR-IFC-01 | Information-flow labels (integrity, confidentiality, tenant, PII class) enforced at sensitive sinks | LLM02 / ASI01, ASI03 / MCP10 | labels.sink, pii.detect |
| GR-OUT-01 | Output handling: no raw HTML, code sandbox, schema validation | LLM05 / ASI05 / MCP05 | code, schema, regex, secrets, file.analyze, file.type, file.active_content, yara |
See it in your own environment.
A one-hour technical demo: your scenario, your policy pack, on a closed-circuit install. Then the install kit and a trial licence for a pilot.