Splenta

BOS / Banking Operations System

Concept

Agent-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

designed mock
  1. 10:42CBSCustomer account debited
  2. 10:42RailOutward IMPS request sent
  3. 10:47RailTimeout - no beneficiary confirm
  4. 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

Glass banking towers against an open sky
Banking towers. Illustrative photo, not a Splenta deployment.

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 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?
A modern bank building facadeOperations
A modern bank building. Illustrative photo.

The safe path

Recommend, then execute only after a human approves.

BOS would tell the operator why a payment failed, show the evidence, recommend the safest next action and act only through human approval. Core banking remains the ledger of truth, and BOS records the complete resolution 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
Glass banking towers against an open skyApproval gate
Banking towers. Illustrative photo.

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 would sit

Where BOS would sit.

BOS places one governed case record between fragmented payment evidence and the people responsible for resolving exceptions.

BOSManual ops todayRecon / RPA tools
What it isA governed case system of record for payment-operations exceptionsOperators correlating five systems by hand, case by caseBatch reconciliation and scripted automation over feeds
EvidenceOne timeline across CBS, payment rails, reconciliation and CRMGathered by hand, screen by screen, per complaintMatches feeds in bulk, not a per-case narrative
ExplanationFailure classification linked directly to supporting evidenceLives in the operator's head and free-text notesFlags breaks; leaves the why to a person
Action safetyActions require human approval; CBS remains the ledger of truthManual and process-dependent; approval variesRPA can act on rules without a per-case human gate
Agent fitArin reads facts and prepares actions; BOS controls executionNo agent surfaceRarely exposes a governed, approval-gated agent surface

Architecture

How the governed loop holds together.

The architecture gives BOS ownership of the exception case, its evidence timeline and the approval boundary around each corrective action.

The resolution loop

One BOS-owned case record carries the investigation from incoming complaint through evidence, classification, recommendation, approval and resolution.

  1. 01

    Open the case

    A complaint arrives with a UTR, RRN or reference. BOS would open or import one PaymentCase with the complaint source, customer reference, SLA clock and current state.

  2. 02

    Gather evidence

    Read-only connectors would pull the CBS debit, rail and switch status, MIS and reconciliation rows, suspense entries and reversal state into immutable evidence snapshots.

  3. 03

    Normalize a timeline

    Facts from every source would reduce to one chronological timeline that operators can read at a glance.

  4. 04

    Classify and cite

    A FailureClassification would name the likely state - for example debit_posted_rail_timeout or suspense_parked - with confidence, reason codes, and links to the exact evidence.

  5. 05

    Recommend an action

    A RecommendedAction would be drawn from a policy-gated catalog - request rail status, raise a beneficiary-bank claim, submit a reversal, send a customer update. Never free-form.

  6. 06

    Approve, then execute

    Maker-checker approval would be recorded before anything runs. BOS—not the agent—would execute the approved action and record the response, audit and customer update.

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 would read permission-filtered BOS facts, prepare an explanation and recommended action, and request execution only after human approval. BOS—not the agent—would validate the request and act through the approved connector.

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 would 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.