VERDOCKAI INFRASTRUCTURE FOR FINANCE AND BANKING
Verdock is the AI infrastructure for running one or many AI agents in finance and banking: inside your own network, within limits you set, with every action checked against your records.
ONE OPERATION, END TO END
An approved refund, used because every step is easy to check.
A case asks for a USD 1.00 refund on one payment. The amount, currency and payment are fixed for this case.
The owner grants permission for exactly that refund. It expires after five minutes and covers nothing else. Publishing a plan never counts as permission to pay.
Product and engineering agents work on the case at the same time, and the support agent waits for both. Their outputs must match the current request before anyone can approve.
Right before sending, the permission, request version and amount are checked again. One request goes out under a reserved request ID. A refund above the USD 5.00 cap is refused here and nothing is sent.
The provider records the refund but its reply is lost. The operation is marked UNKNOWN. It is not retried, and its request ID stays held, so a second refund cannot go out.
An operator reads the refund ID from the provider's own record. A read only check matches the amount, currency, payment and request ID, then moves UNKNOWN to its true state. Nothing is resent.
The operation passes only when the provider record says COMPLETED and matches the approval. Anything else stays open for a person.
CASE STUDY
The same engine run against PayPal's sandbox. Refunds went through PayPal, and each one counted as done only after it matched PayPal's own record.
WHY IT MATTERS
Banks, NBFCs, fintechs and finance teams want agents doing real work. Their data stays inside, and no agent acts unchecked.
Agents run in a network isolated environment. One gateway is the only way out, limited to the hosts your policy names. Cut the network and no money moves. Pending actions wait, then resume only after the provider record is read.
Autonomy levels, approvals, and limits on actions and money sit outside the model and apply across a whole team of agents. Split the work across agents and the cap still holds.
A separate read checks each action against the system of record. An unknown result is never retried blindly. Receipts are signed, and anyone can verify them offline.
THE GAP
I walked founders building AI agents for payments and finance through Verdock. Each one named the same problem: an agent can act, but nobody can prove what it did or stop it at the limit. That is the gap Verdock closes.
Payment platforms are building agents that move money, in public
DEPLOYMENT CHOICE
The engine and agents run on a host you control. Each agent runs in a network isolated container. The team reviews shared outcomes in the online workspace.
Several agents work in parallel. Every run is recorded and open to inspection. Your team reviews outcomes in an invite only workspace.
The engine, worker images and local model are prepared before installation. Work then runs in network isolated containers with no outside connection.
Tested fully disconnected on a Windows laptop, with the host offline before and after. Ships as a portable Windows package.
PILOT
Evaluate one operation against agreed failure cases, demonstrate controlled execution, and deliver a report of verified outcomes and open risks.
Verified here means an outcome passed the agreed checks. Every failure case is agreed in writing before anything runs.
QUESTIONS
No. Agent work runs on a host you control. The online workspace stores only the outcome summaries and team notes that members choose to share.
The engine, worker images and local model are prepared while online, and agent work then runs in network isolated containers. Signing in to the online workspace needs internet. Verdock was tested fully disconnected on a Windows laptop, with the host offline before and after.
No. The refund is one example operation, picked because each step is easy to check. Refunds, payouts and reconciliation are the finance operations it is built for.
Invited members review shared outcomes and add team notes. What each person can do depends on their role. A note cannot approve an action. Access is by invitation.
Yes. Permission is checked again right before each protected action, so a withdrawn permission stops every request before it leaves. A payment already completed stays visible and held for a person to resolve.
Only that a specific outcome passed a stated set of checks, for example that the provider record matched the approved amount, currency and request ID. It describes one outcome, not the whole product.
STATUS
Built means it runs today and is covered by automated tests. Next is what ships after it.
Every agent runs in an isolated container: read only file system, no root user, fixed memory and CPU limits.
One controlled gateway is the only way out, with a signed receipt for every request. Cut the network and money actions hold, then resume only after the provider record is read.
Tested fully disconnected on a Windows laptop, with the host offline before and after.
Signed permissions, budgets and expiry are fixed before work starts, with four autonomy levels. A prompt cannot change a limit.
A maximum per action, an approval threshold, a daily cap per counterparty and one team cap shared by every agent, enforced in the refund tool.
Every completed action is checked against the business record. A run passes only when the final records match the approval.
Hash chained, signed receipts in an open format. Anyone can verify them offline.
Parallel agent teams, plus an invite only online workspace where members review shared outcomes by role.
ROADMAP
This is what ships next.
Models that run on your own hardware, inside the isolation boundary, so no data leaves your network. A local model already runs inside that boundary in trials.
Money moves only through rules the institution set.
Agents run reconciliation, refunds, payouts and disputes every day, with every outcome checked.
Receipts that auditors and payment platforms accept as proof of what an agent did.