Solutions · Use case
Payments & refunds
Let agents move money — inside limits you set, with a human where it matters.
Relevant for Banking & payments, Insurance, Capital markets & wealth
Typical agents
Refund, payments-operations and treasury agents
Systems touched
Payment hubs, core banking, card and refund platforms
Who approves
Payments operations, treasury and fraud teams
The risk
What can go wrong
Payment and refund agents work at machine speed with real permissions. A misread instruction, an injected prompt or a split payment can move money before anyone looks — and the accountability stays with you.
Manipulated instructions
An injected prompt in an email or ticket asks the agent to pay a new beneficiary. The agent has the permission, so the payment goes.
Limits split to avoid review
A large amount is broken into several smaller payments that each fall under a threshold no person ever sees.
No proof of authorisation
After the fact, logs show a payment was sent, but not who authorised it, under which rule, or whether it matched what was approved.
Typical decisions
How GREENLIGHT typically decides
Each action an agent proposes gets one of four outcomes, with a reason a reviewer and an auditor can read.
| Agent action | Typical outcome | Why |
|---|---|---|
| Refund within policy limits | Allow | Amount and payee are within the refund policy. |
| Large outbound wire | Require human approval | Amount is above the threshold that needs a second person. |
| New or changed beneficiary on a transfer | Require human approval | A beneficiary change on a transfer is a consequential change. |
| Payment the rules do not recognise | Escalate | No rule recognises the payment type, so it is not allowed silently. |
| Transfer to a blocked destination | Block | The destination is on a blocked list. |
Illustrative. Outcomes follow your policies and thresholds.
One action, end to end
A large outbound wire, end to end
What happens between the moment an agent decides to act and the moment your system changes. Figures are illustrative.
- 1Agent
A payments agent prepares a S$250,000 transfer to a supplier and asks GREENLIGHT before calling the payment API.
- 2GREENLIGHT
The amount is above the approval threshold, so the decision is require human approval, with the reason and the deciding rule.
- 3Approver
A treasury approver who did not initiate the payment reviews the amount, payee and context, and approves it.
- 4GREENLIGHT
The approved transfer is released once, with an execution visa bound to that amount and payee.
- 5Logbook
The request, decision, approval and release are written to the signed logbook, ready for audit.
How GREENLIGHT governs it
Four parts of the platform, working together
Each part of GREENLIGHT plays a role in this use case. Follow a link to see how that part works.
Policy
Amount thresholds and payment rules from the native library, tuned to your limits.
Define what agents may doDecide
Each payment evaluated for intent, amount and payee before it is sent.
Evaluate every consequential actionEnforce
Large or unusual payments held for an approver; the allowed payment carries a visa bound to the amount and payee.
Act on the decision — and only on the decisionEvidence
Every payment decision and approval on the logbook, ready for audit.
Prove what happened, to anyone who asks
The difference
Without GREENLIGHT, and with it
| Without a decision point | With GREENLIGHT | |
|---|---|---|
| A payment to a new beneficiary | Sent if the agent’s service account allows it | Held for a named approver before it is sent |
| Amounts split under a threshold | Each part passes on its own | Evaluated against your limits and flagged for review |
| Proof for audit or a complaint | Application logs pieced together later | One signed record of request, decision and approval |
Rollout
Start in shadow, enforce when you are ready
For this use case, as for every other, GREENLIGHT starts by watching. Nothing is blocked until you decide it should be.
Shadow
GREENLIGHT evaluates every action and records what it would have decided. Nothing is blocked, so you can measure before you change anything.
Advisory
Decisions are returned to the agent and to your teams as recommendations, and policies are tuned against real traffic.
Enforce
Holds and blocks are switched on workflow by workflow, starting where the risk is highest and the evidence is clearest.
Get started
Start with this workflow.
Bring one Payments & refunds workflow into GREENLIGHT in shadow mode. We will show you what it would decide on your real traffic, then agree with you when to enforce.