Let the agent work the case. Require approval for credit changes.
A dispute case and a payment record show how a banking register separates routine changes from those that need a person’s permit. These are fictional records in the pilot, not transfers of real funds.
Card dispute
A customer disputes a $412 charge. An agent works the case. The example approver is a disputes supervisor.
An example permit table for this case. When the demonstration is connected, you can run it from the home page.
| Action | Limit | Who must say yes |
|---|---|---|
| Move the case between stages | this record, counted uses, a window | Within standing scopeNo additional approval within a valid standing permit. |
| Attach the transaction history | this record, counted uses, a window | Within standing scopeNo additional approval within a valid standing permit. |
| Draft the customer letter | this record, counted uses, a window | Within standing scopeNo additional approval within a valid standing permit. |
| Post a provisional credit | one use, ten minutes, on a person's say | Needs a permitAn employee must permit it (a disputes supervisor). |
| Mark the card as closed | one use, ten minutes, on a person's say | Needs a permitAn employee must permit it (a disputes supervisor). |
| Change where money is paid out | Excluded from this workflow | Never in this workflowThis workflow does not permit this action. |
What the agent proposes
- Open the case for reviewWithin standing scope
Proposed effect: status becomes reviewing.
- Attach the last 90 days of transactionsWithin standing scope
Proposed effect: history attached.
- Draft the acknowledgment letterWithin standing scope
Proposed effect: letter drafted.
- Post a provisional credit of $412Needs a permit
Proposed effect: provisional credit 412.
- Mark the card as closedNeeds a permit
Proposed effect: card closed.
- Pay the refund to a new account the customer mentionedExcluded
Proposed effect: payout instrument changed.
- Close the caseWithin standing scope
Proposed effect: status becomes closed.
Vendor payout change
A supplier emails new bank details. An agent processes the request. The example approver is a treasury controller.
An example permit table for this case. When the demonstration is connected, you can run it from the home page.
| Action | Limit | Who must say yes |
|---|---|---|
| Flag or unflag the vendor | this record, counted uses, a window | Within standing scopeNo additional approval within a valid standing permit. |
| Add a note to the file | this record, counted uses, a window | Within standing scopeNo additional approval within a valid standing permit. |
| Record a call-back verification | one use, ten minutes, on a person's say | Needs a permitAn employee must permit it (a treasury controller). |
| Hold or release payments | one use, ten minutes, on a person's say | Needs a permitAn employee must permit it (a treasury controller). |
| Change the bank account | Excluded from this workflow | Never in this workflowThis workflow does not permit this action. |
| Change a payment amount | Excluded from this workflow | Never in this workflowThis workflow does not permit this action. |
What the agent proposes
- Flag the vendor for a details changeWithin standing scope
Proposed effect: status becomes flagged.
- Note the email and its headers on the fileWithin standing scope
Proposed effect: note added.
- Hold the next payment until verifiedNeeds a permit
Proposed effect: payment on hold.
- Record the call-back to the number on fileNeeds a permit
Proposed effect: contact verified.
- Update the bank account to the one in the emailExcluded
Proposed effect: bank account changed.
- Release the payment holdNeeds a permit
Proposed effect: payment hold released.
The questions that come first
- What does it do to my dispute flow?
- An integration must route the declared record updates through the gate, and your system of record must refuse alternate agent credentials. Your team still owns its regulatory process.
- Who approves what?
- The register separates fields within standing scope, fields that need a permit and fields excluded from this workflow. When the demonstration is connected, you play the supervisor and request a standing or one-use permit. This site refuses to request a permit for an excluded field. The backend evaluates the permit it receives; the register itself is not a backend policy.
- Can I set a dollar limit, such as credits under $50 run on their own?
- G-14 rules can combine amounts with checks and operating state, for example credits under $50 within standing scope and larger ones needing a supervisor’s decision. Other limits still apply. This demonstration limits records, fields, uses and time only, so every credit in it needs a permit.
- What if the approver is out?
- In this demonstration, the action stays denied until someone with the authority issues the permit. Nothing is admitted by default and nothing waits in a queue no one owns.
- What does my examiner see?
- For each returned decision: a signed record of the request, decision, reason and applicable events, which a reviewer can check with a compatible ECL-1 verifier under the trust policy they choose. In this demonstration, the signatures use public test keys, so a passing check shows the record is intact, not who made it or that the event happened. The record names the permit, not the person who issued it.