Every figure, with its source
Statements, policies and filings read into fields and answers you can trace, on a model pool you can name to an auditor, with a receipt on every call.
The work is careful. The volume is not small.
A thousand statements arrive as PDFs every month.
Someone keys them in. Someone else checks the totals.
The answer is in the policy. Nobody can find it.
The analyst asks a colleague, who asks compliance.
One misread total reaches a client report.
The audit asks which system produced it. Nobody can say.
Every number needs a source.Every source needs a record.
The situations, and the guide that builds each
Every one is a build guide: the architecture, the policy, the code that was run, and what was measured.
Statements, invoices and forms into your ledger
Documents into fields that match a schema you define, validated against your own rules, with idempotent retries and a review queue for what does not add up. Every record keeps the model and the cost that produced it.
Build guide: Document extraction to JSON
Questions over policies, procedures and regulation
Retrieval over your own policy library with the answer cited to the passage it came from, routed per question so a lookup stays cheap and a cross-reference gets a strong model.
Build guide: RAG over a knowledge base
Operations that act, with a person on every write
An agent that reads accounts and cases through tools named in a policy. Reads run at once; any change waits for approval, and every run is one record with its tool calls.
Build guide: Agents with tools and MCP
Client questions on your website
A chat that answers from your published terms and help pages with a citation, refuses what it should not answer, and hands an account question to a person with the conversation attached.
Build guide: Customer support assistant
Routine calls on the service line
A turn-based voice assistant for balances, hours and branch questions. Measured honestly at 7 to 13 seconds a turn today, which fits an IVR and not yet a conversation.
Build guide: Voice agentWhat changes for financial services
Documents that must become fields without a mistake, policies and regulations to answer from with a citation, and actions that wait for a person.
A source for every answer
Answers cite the passage they used, extractions keep the document they came from, and every response carries the request id that reads back why its model was chosen.
A pool you can show an auditor
The routing policy names the models that may see client data, and nothing outside it is ever chosen. Your own provider keys or cloud accounts keep the call inside contracts you already hold.
Nothing kept that you did not allow
Request content is kept for up to 30 days by default and not at all with zero retention on the key or the organisation. The routing decision is kept without the content.
Writes wait for a person
The tools an agent may call are an allow-list in the policy, dry-run first, then enforced. A change to an account waits for approval and is recorded with who approved it.
Figures with a source
Every number here was measured by us and says when. Where nothing was measured, nothing is claimed.
| One short document extracted to JSON, non-streamed | 1.8 to 3.2 s | Measured 2026-10-14, three runs, client-side from India |
| The verified invoice extraction, one document | about $0.0002 | Document extraction guide, run against the API on 2026-10-13 |
| Time to decide (classify and rank), live traffic | p50 18 to 31 ms | Gateway classifier timer, 2026-10-13 |
| Requests that returned HTTP 200 in the load test | 100% of 1,272 | Load test against the public API, 2026-10-12 |
Questions from financial services teams
Yes. Each record stores the document reference, the schema version, the model that produced it, its cost and the request id. The request id reads back the full routing decision, so a figure in a report can be followed to the call that made it.
Validation runs after the call: the schema checks the shape, your rules check the sense, such as line items summing to the total. A record that fails goes to a review queue with the raw output and the reason, and a reviewer's correction becomes a test case.
Only the models in your routing policy pool. A pool you name is a list you can show an auditor, and a request can narrow it but never widen it. Your own provider keys or cloud accounts run the call inside your existing contracts.
Request content is kept for up to 30 days by default and can be deleted at any time. With zero retention on the key or the organisation it is not kept at all; the routing decision is kept without the content.
Yes. The retrieval design numbers the passages it found and the prompt requires a citation after each sentence. When the passages do not settle a question, the answer says so rather than guessing.
Through tools you define, under a policy that lists which tools a key may call. Reads run at once; writes wait for a person to approve, and a declined write is reported rather than retried. Every run is recorded with its tool calls.
No. OCR, storage, search and your ledger stay where they are. The generation call goes to Inferbase with the model set to auto; the OpenAI SDK with the base URL changed is the whole integration.
The response carries the cost in micro-dollars, the same figure Usage shows, so a record can store what produced it. The verified invoice extraction on the guide cost about $0.0002; your documents and pool return their own figures.
Whichever models in your policy pool win on the objective for each request: a cheap model for a clean statement, a strong one for a long filing with tables. The response always names the model that served.
Put intelligence in the middle.
One gateway in front of every model, with your policies applied and every decision on record. Start on the free plan with 5,000 requests a month, no card required.