Financial services
Your teams are already using AI. Can you prove what it did?
Inside every bank, lender, insurer, and fintech, product teams are calling LLMs today, through scripts, agents, and vendor tools. The question coming for your compliance team is not "should we use AI." It is "show me what went where." RemKey is the layer that produces that answer: every call screened, signed into a tamper-evident chain, and exportable as a bundle your auditor verifies offline without trusting us.
Start with the calls nobody logged
Before any audit question, most firms have a more basic one: the LLM calls no one wrote down. A developer points a coding agent or a script straight at a provider in minutes, and nothing records that it happened. That is the gap a review actually trips on, and it is invisible to any dashboard that only sees the traffic that came through it. Here is a scan of a sample repository turning up four ungoverned calls, next to the one that was already routed through the gateway:
RemKey governs every call routed through it today, and this kind of scan surfaces the ones that slipped past. Proving coverage across a whole estate, so ungoverned becomes the harder path rather than the default, is what we are building with design partners now. We would rather show you that roadmap honestly than imply it already ships.
The questions you're already being asked
Regulators and auditors are converging on the same handful of questions about AI in regulated workflows, whether the frame is model risk guidance, technology risk guidance, or a SOC 2 audit. Here is how each one maps to something RemKey actually produces, per request, automatically:
| The question | The evidence RemKey produces |
|---|---|
| Which model handled this request, and why? | Every request logs the model, the routing decision, and the classifier tier that drove it, on a hash-chained ledger row you can retrieve by the id returned in the response headers. |
| Did customer PII leave the building? | Every prompt is screened for PII (email, SSN, phone, card, API keys) and prompt injection before it reaches any provider, fail-closed, and the guardrail action lands on the same chain. |
| Can you prove this log wasn't edited after the fact? | Rows are hash-chained back to genesis and the export is Ed25519-signed. Tampering with, deleting, or reordering any past row breaks every hash after it. Your auditor checks the export with a standalone verifier, offline, with no call back to us. |
| Who was the end user, and what session was this? | Pass an opaque user id and session_id on the request and both are
recorded on the ledger row, so a finding can be traced to a person and a conversation without
storing any prompt content. |
| What are your AI agents' tools allowed to do? | MCP tool-calls run against a fail-closed allowlist. Unknown tool or scope is blocked by default, and blocked calls are signed onto the audit chain too. |
| How long do you keep the records? | The Compliance plan holds the signed chain for 1 to 7 years, matched to your retention obligations, as a flat annual platform fee rather than a variable bill. |
Evidence, not attestation
Being precise about what RemKey is: it is not a certification and it does not make your firm compliant with anything by itself. What it does is produce the evidence trail your existing obligations keep asking for, in a form that stands on its own math instead of on our word. Your model-risk documentation cites the routing ledger. Your data-handling answer cites the fail-closed guardrails. Your records-integrity answer cites the signed chain and the offline verifier. SOC 2 Type II for RemKey itself is on the roadmap and we will show you the current state in the first call rather than hint at it on a website.
What your prompts touch, and what they don't
- Prompt and response text is never written to the audit chain. The chain holds metadata: model, tokens, cost, routing decision, guardrail action, end-user id if you supply one.
- Quality verification is optional per request. A sampled downroute sends
content to a judge model in the background to prove the cheaper answer held up. Set
x-remkey-no-verify: trueon any request and that sampling never happens for it. - Your provider keys stay yours. Bring your own Anthropic, OpenAI, or OpenRouter keys, encrypted at rest, revocable instantly from the dashboard.
What adoption actually looks like
One base URL. Your teams keep the OpenAI or Anthropic SDKs they already use, and every call they make is governed from the first request. There is no agent to install, no sidecar, no six-week integration project, which matters when the goal is getting the whole firm's AI traffic onto one evidence trail rather than one team's.
- Point one internal tool at RemKey and watch its traffic land on the signed chain the same hour.
- Export a bundle and hand it to your auditor with the standalone verifier. Let them try to break it.
- Roll the base URL out by team, with per-environment policy and spend caps as you go.
We're selecting a small group of financial-services design partners. Discounted annual pricing in exchange for a logo, a case study, and a monthly feedback call that shapes the roadmap. Email sales@remkey.ai, or read the trust page first to see how we govern ourselves.