Start with rules.
Check payment references, amounts, currencies and duplicate identifiers with explicit rules. Integrations bring the agreed records together; tests cover the ordinary cases and exceptions.
HOW WE USE AI
AI does the legwork.
Your team keeps the authority.
What may it access? What may it change? Who approves? What evidence checks the result against the agreed criteria?
In payment operations, a useful investigation must lead to a supported decision. We define the permitted records, approval points and outcome checks before an agent gets access to your systems.
Enter the payment workspaceTHE BUSINESS QUESTION FIRST
Match with rules.
Investigate with context.
Exact payment references, amounts and currencies can be checked with deterministic rules. An unusual remittance, disputed reference or missing context may need interpretation across several permitted records. That is where a bounded AI investigation can help prepare a next step.
The proposed action stays separate from the authority to perform it. A reviewer can see the evidence and exact change, and required approvals are checked again alongside current facts before the action is applied. Missing evidence and unresolved outcomes remain visible.
We assess the existing tools first and use the simplest approach that meets the goal. Representative cases, refusal scenarios and recovery checks establish what a customer workflow can support. The website workspace demonstrates that proposed experience with fictional data and scripted decisions; it does not run a live model.
WHAT / WHY / WHEN
Choose the tool.
Define the responsibility.
Use AI with a checking path.
An agent can gather permitted supporting records and prepare an explanation for a discrepancy. Define useful evidence, evaluate representative cases and send unsupported conclusions to a person.
Define authority first.
Specify permitted actions, limits, required approvals and who can pause the work. Recheck changing facts before applying an approved action, inspect the result and hold uncertain outcomes for investigation before retrying.
THE ENGINEERING BEHIND OUR APPROVAL LAYER
AI Institution.
Approvals for AI agents.
The approval steps above are the subject of our own engineering project. It is where we test how far an agent can be trusted with a consequential action, such as a refund.
AI INSTITUTION / APPROVAL LAYER
Exact limits, separate sign-off, an independent check.
Early development · self-hostedAn AI agent can prepare a change but can’t approve it. The right people sign off the exact action, facts are rechecked before money moves, and a separate check confirms the result. Every step leaves a receipt, not just a status badge.
AI Institution is early, private and self-hosted, with limited reference workflows and demonstrations. A payment pilot does not require it. Its refund example uses a scripted model and simulated Stripe; customer-feedback and research-report examples also have stated test boundaries. A customer payment workflow still needs its own integrations, checks and operational acceptance. These examples are engineering evidence, not customer deployment claims.
See an approved refund stop when the facts changeFOR ENGINEERING TEAMS
Coding-agent projects.
Separate from the payments work: open-source tools for teams whose coding agents can run commands and change code.
WARDOS / EXECUTION
What can the working environment reach?
Open source · in developmentWardOS develops a Linux workstation and execution runtime for coding agents. Isolated project environments, host-held credentials and independent verification address the boundary between work an agent may perform and authority it should not hold.
This matters when a coding assistant can run commands and interact with a development environment. The project documents prerequisites, trust boundaries and limitations, so an operator can evaluate the setup rather than rely on the word “sandbox”.
Explore WardOS and its boundariesTAMPERWARD / VERIFICATION
Who controls the checks?
Open source · research releaseA coding agent may be able to edit implementation, tests and the configuration used to judge success. Tamperward investigates that verification-integrity problem: protecting the trusted starting point and checking apparent success independently.
It is an active research release, with findings and limitations published alongside the work. It supports software verification within a wider process of protected CI, independent tests and human review. It is not a correctness oracle for financial records or business decisions.
Explore Tamperward and the evidenceFOR YOUR BUSINESS
A practical first step.
Something you can assess.
A Payment Operations Pilot starts with one recurring workflow: matching records, investigating exceptions or preparing a repeatable finance report. Establish the baseline, define access and approval boundaries, and agree what a useful improvement must achieve.
The agreed pilot combines the required integrations, deterministic processing and, where useful, an AI investigation step. Review staff effort, unresolved exceptions, errors and running costs against the baseline. Handover documents the limitations and the owner of each operational responsibility.
The same care applies to ordinary software. Hamsa’s professional work in payment systems, finance automation and integrations provides the business delivery context behind this specialism.
Explore the Payment Operations PilotExplore the projects and their current development stages
ENGINEERING BEHIND THE APPROACH
Research you can inspect.
Limits we explain.
Our own projects explore verification, execution and authority. Their published scope and maturity matter when assessing any deployment.
Tamperward
Investigating whether the checks around agent-written code remain trustworthy.
Open source · research releaseWardOS
Exploring bounded workspaces, host-held credentials and verification for coding agents.
Open source · in developmentAI Institution
Developing authority, approvals, recorded evidence and recovery for delegated work. Customer finance workflows need their own integrations and checks.
Early development · private · self-hosted