Splenta

BOS / Banking Operations System

BlueprintIn design, not yet built

Agent-ready banking
exception resolution.

This page describes the intended design for a system of record that resolves banking-operations exceptions, starting with the debit-but-not-credited complaint. No software has been built yet.

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.

What the blueprint designs

Four things the design is built around.

The blueprint is narrow and safe by intent: explain why a payment failed, show the evidence, recommend the safest next action, and act only after a person approves. These are the designed capabilities, not features you can use today.

Evidence

One evidence timeline

Designed to pull core banking, the payment rail, reconciliation and the complaint queue into one chronological timeline you can read at a glance.

Classification

A cited failure classification

Designed to name the likely failure state - with confidence and reason codes - and link each one to the exact evidence behind it.

Action

Human-approved, CBS-safe action

Designed so every action is drawn from a policy-gated catalog and runs only after a person approves. Core banking stays the ledger of truth.

Audit

A full audit trail

Designed so every fact, recommendation, approval and executed action is captured on the case - idempotently, in order, and reviewable.

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 even answer the customer, let alone trigger a fix. The blueprint targets exactly this first: the 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.

The blueprint's thesis is not that AI fixes payments automatically. It is narrower and safer: tell the operator why the payment failed, show the evidence, recommend the safest next action, and act only through human approval. Core banking stays the ledger of truth and nothing runs on its own. The designed approval gate itself lives further down, in the designed architecture.
  • Designed to recommend from a policy-gated catalog, never free-form
  • Designed so a person approves before any action runs
  • Designed so BOS - not the agent - validates and executes, idempotently and audited
Glass banking towers against an open skyApproval gate
Banking towers. Illustrative photo.

The designed resolution loop

One designed loop, from complaint to executed action.

The blueprint models the whole resolution as one ordered loop over a BOS-owned case record - it recommends first, then executes only after a person approves. Every step is designed, not built.

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.

If it were built, BOS would sit between today's manual exception handling and the reconciliation and RPA tools banks already run. This is a designed positioning, not a benchmark - the neighbours keep their real strengths.

BOS (designed)Manual ops todayRecon / RPA tools
What it isA designed case system of record for payment-operations exceptionsOperators correlating five systems by hand, case by caseBatch reconciliation and scripted automation over feeds
EvidenceDesigned to assemble one timeline across CBS, rail, recon and CRMGathered by hand, screen by screen, per complaintMatches feeds in bulk, not a per-case narrative
ExplanationDesigned to cite a failure classification linked to the evidenceLives in the operator's head and free-text notesFlags breaks; leaves the why to a person
Action safetyDesigned so actions run only after human approval - CBS stays the ledger of truthManual and process-dependent; approval variesRPA can act on rules without a per-case human gate
Agent fitDesigned for Arin to read facts over MCP and prepare actions, never executeNo agent surfaceRarely exposes a governed, approval-gated agent surface
MaturityBlueprint, Draft v0.1 - not builtIn place at most banks todayMature, proven products in production

BOS is a blueprint, not a product. This positioning is designed and clearly hypothetical. Manual operations and reconciliation / RPA suites are real and in production today; BOS is documentation only, with no software behind it. The table shows where the design would sit, not a claim that it beats anything.

The designed architecture

How the blueprint would hold together.

The story above is the plain version. For evaluators, here is the architecture the blueprint describes - the exception-resolution loop and the agent surface. All of it is designed, not built. There is no running service, connector or data behind any of it.

The designed resolution loop

The blueprint models the whole resolution as one loop over a BOS-owned case record, with safe execution and a full audit trail. Every step is designed, not built.

  1. 01

    Open the case

    A complaint arrives with a UTR, RRN or reference. BOS is designed to open or import one PaymentCase - complaint source, customer reference, SLA clock, current state.

  2. 02

    Gather evidence

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

  3. 03

    Normalize a timeline

    Facts from every source are designed to reduce to one chronological TimelineEvent stream you 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 is designed to be recorded before anything runs. BOS - not the agent - would execute the approved action through its connectors, idempotently, and write 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

Designed mock . not working software

The designed bos.payment_case.* MCP surface

In the family design, Arin never calls core banking directly. It would read normalized, permission-filtered BOS facts over MCP, prepare an explanation and a recommended action, and call a BOS action only once a human approval is on record. BOS - not the agent - would validate and execute. This mirrors the pattern already proven in the family, Arin to SCM po.approve. None of it is built for BOS.

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

Blueprint - in design

Help shape the Banking Ops blueprint.

BOS is a design document in the Splenta AiStack family - no software, no customers, no overclaiming. If banking-operations exceptions are eating your team's day, we would like to hear how you resolve them today, and shape this design with you.