Home/Solutions/Financial services
Financial services
Move essential work forward. Keep every change accountable.
Nobody in this industry objects to automation. They object to automation that acts on a production host and then reports on itself. The examiner's question is never "did the tool run" — it is who allowed it, what rights it held, who verified the result, and what the plan was if it went wrong. Seraph produces all four as a by-product of doing the work, on the same clock as the cut-off you are trying to meet.
The characteristic ticket
16:40, and the custodian feed cuts at 18:00.
The end-of-day reconciliation service on the mid-office host has stopped. Everything downstream of it is queued. There is a hard cut-off at 18:00 and a change process that, sensibly, does not want anybody improvising on a production box. The temptation is to hand somebody standing admin rights and hope the write-up gets done tomorrow. What you actually need is for the fix to be bounded, and for the outcome — either outcome — to be known while there is still time to act on it.
The artifact
What the change record actually contains.
Your change process already has a template. The gap is never the template — it is that half the fields are filled in afterwards, by the person who did the work, from memory. These fields are produced by the operation itself, at the moment each one becomes true.
- Nothing here is written by the model. The confirmation row can only ever carry what the target answered.
- Your technician remains a first-class actor. Taking the wheel mid-operation mints a fresh lease under their own identity, in the same operation and the same record — see commanded autonomy.
- Exports are unmetered on every plan, in PDF, CSV and JSON. A platform that charges per record teaches you to ration your own evidence.
The person who asks
Every control question maps to a step of the operation.
This is the diagram we would draw on a whiteboard for an internal-audit lead or a third-party-risk reviewer. On the left, the questions they have to be able to evidence about automated change on a production system. On the right, the point in the operation where the answer is produced — not compiled later, produced.
The same shape, different clock
Two more places this lands.
A desk workstation, before the open
08:52. A market-data client will not reconnect on a trading-desk machine, and the desk policy quite reasonably forbids restarting anything after 09:00. The fix has eight minutes, and the machine cannot simply be taken away.
Same loop: a typed outcome, a named authorization, a lease scoped to that one workstation, and a check on the machine itself. If the precondition fails — a step that would sign the trader out — the operation stops and asks rather than deciding for you.
How a technician runs several at once →Patching a fleet without a leap of faith
Quarter-end is exactly when a wave of updates is least welcome and most overdue. A certified-runbook-first workflow runs it as a governed wave — canary, then rings — where a gate opens on a verified result from the target rather than on a job having been dispatched.
A failed canary is planned to halt the wave and fire the declared back-out. Every machine in the wave gets its own record, so the reporting to the business is the evidence, not a summary of it.
Governed waves →The questions a security committee asks us.
Does the AI hold standing access to our production systems?
No. There is no standing account for it to use. Privilege is requested per operation, granted against one target, recorded with its justification, and revoked on expiry rather than on completion — so a stalled job cannot hold rights open. This is the first of the six questions we think you should put to every vendor, including us: the spec is published.
Can the model retrieve a credential at any point?
No. The connection is authenticated before any generated step exists. The planner is given the operation type, the target and the outcome to reach; the executor resolves a credential reference to a value the model is never handed. Not redacted, not masked — not delivered. How the vault draws that line.
Who decides that a change succeeded?
The machine that was changed. An independent check runs on the target after the work, and its answer is what the record carries. If that check did not run, the record says so rather than going quiet. This is the single hardest thing to retrofit into a tool that was built to report on itself, and it is why we lead with it.
Can we run it in observe-only mode first?
Yes — autonomy is a setting, and the strictest setting proposes and does nothing until a human says so. What does not change across the settings is the rest of it: leased privilege, model-blind execution, target verification and the record. Autonomy changes when a human authorizes, never whether the work is proven. The dial, explained.
How is one client's data kept away from another?
Records and storage are isolated per tenant, with client policies and branding held separately. For a group with subsidiaries, the mapping rule is one-way by design: a primary may reach into its own sub tenants, never the other direction and never sideways — and that binds automated actors exactly as it binds people. How the walls are drawn.
Straight about scope
What we do not claim here.
- We supply evidence; we do not attest. We are not your assessor and we do not audit you — we produce the operational record your assessor asks for. Our own SOC 2 position is on the trust center.
- No trading or market-system integration. Seraph works at the machine, service, account and update layer beneath your applications.
- No claim to enforce your separation of duties. The record names the requester and the approver, which makes the control checkable. Deciding who may approve what is your policy, not our feature.
- No complete session recording. Where a person has to be on a machine, we describe governed launch, authorization and binding to the operation, and stay narrow about what the session record covers today.
The most useful sentence on this page may be the one about failure. Any vendor can show you a green path. What an examiner is actually testing is whether your evidence survives the day something went wrong — and the honest position is that a failed operation is common, is not embarrassing, and must produce the same record as a successful one, including "no response captured" when a target never answered. If a demo only ever shows you the happy path, that is the thing to push on. Ours included.
Fifteen minutes, on a live system
Bring the finding from your last internal-audit review.
We will run an operation, break it deliberately, and show you the record the failure produces — then execute the declared back-out while you watch.