The institution supplies the policy
We seed no legal windows and no customer policies. You set the timezone, the cutoff, your working days and holidays, the deadline windows, how early you want warning, and what counts as grounds for an extension.
BOS / Banking Operations System
Case system of recordAgent-ready banking
exception resolution.
BOS brings fragmented payment evidence into one governed case record, beginning with debit-but-not-credited complaints and the decisions required to resolve them.
Case DBT-1042
Debit, but not credited
- 10:42CBSCustomer account debited
- 10:42RailOutward IMPS request sent
- 10:47RailTimeout - no beneficiary confirm
- 11:05ReconUnmatched outward item
Classifieddebit_posted_rail_timeout
Recommended: request rail status now; trigger a reversal after settlement cutoff if no credit confirms.
Awaiting your approvalHITL required
Arin recommends - a person approves - BOS executes
Exception operations
Four controls for safer exception resolution.
Explain why a payment failed, connect the evidence, recommend the safest next action and execute only after a person approves.
Evidence
One evidence timeline
Bring core banking, payment rails, reconciliation and the complaint queue into one chronological timeline.
Classification
A cited failure classification
Name the likely failure state with confidence and reason codes linked to the supporting evidence.
Action
Human-approved, CBS-safe action
Draw every action from a policy-gated catalog and run it only after a person approves. Core banking remains the ledger of truth.
Audit
A full audit trail
Capture every fact, recommendation, approval and executed action on the case in a reviewable sequence.
The regulatory frame
The deadline is the work.
A payment dispute is not an open-ended investigation. It is a clock with a date on it. BankOps is built US-first, around the rails that actually fail and the rules that set the deadlines.
Rails
ACHFedwireRTPFedNowZelleCardsCheck (Reg CC)
Regimes
Reg EReg ZReg CCNACHAUCC 4ACard-network rules
Twelve case types, and what you chase for each
Sent but not creditedReg E · UCC 4AACH trace, Fedwire IMAD/OMAD, RTP id
Unauthorized electronic transferReg ETrace number, card ARN, device id
Duplicate debitReg ETrace numbers, posting ids
ATM cash not dispensedReg ETerminal id, electronic journal, switch log
Debit card transaction disputedReg E + networkARN, RRN, authorization id
Credit card billing errorReg ZStatement cycle, posting id
Refund not received from merchantReg E / networkMerchant refund ref, settlement file
ACH return or reversalNACHATrace number, return code
Revoked ACH still debitingReg E + NACHAAuthorization id, trace numbers
Check deposited, not availableReg CCCheck number, image, return reason
Hold, freeze, garnishment or levyState law + policyHold id, legal order reference
Wrong or misdirected beneficiaryRecall request rulesTrace number, beneficiary details
These twelve are a starting point and carry no deadlines. Your team reviews them before you use them, and every version after that is locked and signed. For India and other markets you swap the rail and rule packs. The case model stays the same.
Regulatory clocks
We never invent your deadline.
A system that ships with the legal windows already filled in is telling you what your compliance policy is. We do the opposite. You give us a reviewed policy for each regime, and the clock does exactly what it says. Or it tells you it cannot.
Notice date is day zero
Calendar-day windows count every day. Business-day windows skip your non-working days and holidays. Billing-cycle and network deadlines can take a real due date instead of a rough day count.
A running clock is never rebased
Saving a policy creates a new version. New clocks use it. Clocks already running keep the policy, notice date and deadline they started with. Updating a policy never moves a deadline that is already counting down.
An uncalculable clock says so
If we cannot work the deadline out, the case says Clock not started until someone fills in the missing dates. We never quietly backfill old cases, and a notice date in the future cannot start a clock.
Extensions name their basis
An extension has to name its grounds in the policy, with evidence and a note. A moved deadline always carries the reason it moved.
BankOps owns the case. The evidence, the clock, who approved what, and the audit trail. It owns none of the money. Your core system keeps the ledger, the networks keep settlement, reconciliation keeps the match, and CRM keeps the complaint. BankOps reads them and records what you decided.
The problem
A payment fails, and the answer is scattered across five systems.
A customer says the money left their account but never arrived. The truth is spread across core banking, the payment switch, reconciliation, suspense and the complaint queue. An operator opens every one of those screens and correlates them by hand before they can answer the customer or trigger a fix. BOS focuses first on this debit-but-not-credited exception.
- Core banking (CBS): did the debit post, and was it reversed or adjusted?
- Payment rail / switch: timeout, reject, or still pending at the beneficiary bank?
- Reconciliation / MIS: matched, unmatched, or parked in suspense?
- Complaint / CRM: what did the customer report, and what is the SLA clock?
The safe path
Recommend, then execute only after a human approves.
BankOps tells the operator why a payment failed and shows the evidence. It recommends the safest next step, and only acts once a person approves. Your core system stays the ledger. BankOps keeps the trail.
- Recommendations come from a policy-gated catalog, never free-form
- A person approves before any action runs
- BOS—not the agent—validates, executes and records the outcome
The resolution loop
One path from complaint to resolution.
Each exception moves through one ordered loop over a BOS-owned case record: assemble evidence, explain the failure, recommend an action, obtain approval and record the outcome.
01
Open the case
Complaint + reference
02
Gather evidence
CBS, rail, recon, CRM
03
Normalize the timeline
One event stream
04
Classify + cite
Failure state + evidence
05
Recommend
From a gated catalog
06
Approve
Maker-checker gate
07
Execute
BOS acts, idempotent
loops back
Where it sits
Where BankOps sits.
BOS places one governed case record between fragmented payment evidence and the people responsible for resolving exceptions.
Architecture
How the governed loop holds together.
BankOps owns the case, its evidence timeline, and the approval step in front of every action.
The resolution loop
One BOS-owned case record carries the investigation from incoming complaint through evidence, classification, recommendation, approval and resolution.
- 01
Open the case
A complaint arrives with a trace number, an IMAD or OMAD, an ARN or an RRN. BankOps opens one case with the source, the customer reference, the clock and the current state.
- 02
Gather evidence
Read-only connectors pull in the debit, the rail and switch status, reconciliation rows, suspense entries and any reversal. Each one is kept as a snapshot that cannot be edited.
- 03
Normalize a timeline
Everything we gathered becomes one timeline, in order, that an operator can read at a glance.
- 04
Classify and cite
A classification names the likely state, such as debit posted but the rail timed out. It comes with a confidence level, reason codes, and links to the evidence behind it.
- 05
Recommend an action
Recommended actions come from a fixed list your policy allows. Ask the rail for status, raise a claim with the beneficiary bank, submit a reversal, update the customer. Never free text.
- 06
Approve, then execute
One person proposes, another approves, and that is recorded before anything runs. BankOps performs the action, not the agent, and logs the response.
Evidence / Case DBT-1042
3 sources- CBSDebit posted to customer accountconfirmed
- RailOutward leg accepted, no credit confirmno confirm
- ReconCredit not found - unmatched outwardmissing
Classifieddebit_posted_credit_missing
Awaiting your approvalHITL required
The BOS agent surface
Arin reads what it is allowed to see, writes an explanation and suggests an action. It can only ask for that action once a person approves. BankOps checks the request and carries it out.
Fact resources (read)
- bos.payment_case.get
- bos.payment_case.search_by_reference
- bos.payment_case.timeline
- bos.payment_case.evidence
- bos.payment_case.recon_status
- bos.payment_case.action_options
Action tools (gated)
- bos.payment_case.record_recommendation
- bos.payment_case.request_hitl_approval
- bos.payment_case.execute_approved_action
- bos.payment_case.send_customer_update
arin -> bos.mcpapproval required
POST bos.payment_case.execute_approved_action
{
"case": "DBT-1042",
"action": "submit_reversal_request",
"approval_ref": null,
"idempotency_key": "rev-DBT-1042-01",
"evidence_ref": "snapshot@11:05"
}
<- 409 no_active_approval
BOS executes nothing. Arin cannot bypass the gate.
By design, only an on-record approval, valid action, allowed actor, idempotency key and current snapshot unlock execution.
Shape the concept
Help shape banking exception resolution.
If payment exceptions are consuming your operations team's day, tell us how evidence is gathered, decisions are approved and resolutions are executed. Your operating reality will help shape the BOS design.