# Financial-services operations: a business-to-code workbook

Build an internal status handoff for an invented U.S. consumer debit dispute. Begin with the [visual Financial-services business 101 lesson and original video](/training/fde-101?topic=finance-business#concept). The Academy course adds architecture, worked examples, checks, code proof, financial reconciliation, transaction safety and a receiving-owner review.

You need Python 3.11 or newer, a terminal and a local folder. No bank account, API key, model or network connection is required. Estimated working time: 60–90 minutes, including review rehearsal. This exercise never moves money, decides liability or calculates legal deadlines.

## 1. Translate the business language

“The money is back. Is the dispute over?” Separate the accounting event from the case outcome. Temporary credit can coexist with an open investigation.

| Term | Plain meaning | Engineering consequence |
| --- | --- | --- |
| Transaction | The referenced business event | Keep its identity separate from a case ID |
| Ledger entry | A recorded accounting change | Verify kind, amount and references |
| Dispute / error notice | A reported problem | An allegation is not a finding of fraud |
| Provisional credit | Temporary credit in the applicable investigation process | Do not label it a final outcome |
| Final credit | Credit made final through the authorized process | Require the matching case evidence |
| Reconciliation | Comparing related records and resolving differences | Missing or conflicting evidence needs an owner |
| Idempotency | One operation identity for an unchanged retry | Changed content is a conflict, not a replay |

Add case owner, product type and jurisdiction to your dictionary. Consumer debit, credit-card billing, commercial accounts and lending are different domains; do not copy a single legal timetable across them. The policy owner must validate applicability and deadline logic.

## 2. Specify the smallest useful workflow

Scope this assistant to a private case handoff. It reads permitted case evidence, derives supported wording, drafts a note, obtains review and writes that note once. It does not issue credit, determine fraud, close a dispute or send a customer notice.

Draw read-case → meaning check → draft → review → note writer. Show where identity is established and where each source is loaded. Customer messages and documents are input, not authority. Separate a known pending investigation from an unknown technical outcome after a timeout.

The synthetic case source says `dispute_case / provisional_credit`. The supported note is `temporary_credit_recorded`. The proposal `final_credit_recorded` goes beyond the evidence. An accepted review cannot create an absent final case outcome.

## 3. Run the proof lab

Start with the 101 lesson’s **Try it** stage: predict a handoff, inspect its actual saved notes, and compare the deliberately broken meaning check. The browser presents recorded observations from this same Python lab. Then reproduce them locally below.

The JSON `attempts` array preserves each delivery’s exact `input`, database `before`, `result`, and database `after`. For a retry, inspect attempt two rather than reusing the first delivery’s source. A review must match the exact case ID, proposed note, case revision and source revision. Add an unseen test that changes the case ID or reviewed note; verify `review_content_mismatch` and no new row.


Download the Python file into an exercise folder. Every scenario gets a fresh in-memory SQLite database, so the reports are reproducible and isolated from your platform account.

```bash
python3 fde-industry-proof-lab.py --domain finance --json > finance-guarded.json
python3 fde-industry-proof-lab.py --domain finance --omit-meaning-check --json > finance-broken.json
```

Predict the following before opening the reports:

| Scenario | Evidence to inspect |
| --- | --- |
| supported | A temporary-credit note is stored |
| meaning-trap | The guarded run withholds final wording; the broken run stores it |
| missing-evidence | A model summary is not the expected case source |
| stale-review | The earlier review cannot cover a changed source revision |
| wrong-workspace | A different workspace's review is rejected |
| wrong-reviewer | The drafting agent cannot accept its own proposal |
| specialist-question | Dispute adjudication leaves this handoff flow |
| identical-retry | The second attempt adds no note |
| changed-retry | The first note remains and changed content conflicts |
| supported-final | A source that actually records final credit supports final wording |

Inspect `source`, `proposal`, `outcomes` and `saved_notes` together. Both scripts can exit successfully. Only one preserves the intended business meaning in `meaning-trap`. Valid JSON, accepted review and a successful SQL write do not prove that the statement is supported.

For a compact report:

```bash
python3 fde-industry-proof-lab.py --domain finance
```

## 4. Change the code and design the deployment boundary

In a copy, add an `unknown-state` scenario using `replace(base, observed_state="unrecognized")` and a rejected-review scenario using `replace(base, review="rejected")`. Predict, run and inspect zero new notes for both. Propose how a new business state would be reviewed before adding it to the policy table.

The `Packet` values are trusted fixtures. A production API must load workspace, source and reviewer authority on the server; it must not accept them as claims from a model or browser. The local sequential exercise does not prove concurrent retries, source changes during a write, real ledger reconciliation or regulatory deadline behavior. Write an integration test contract for each boundary you would need.

Go deeper with the [financial reconciliation lab](/training/guides/financial-reconciliation): compare case and credit records, distinguish repeated delivery from two distinct entries, and give unresolved differences an owner.

Keep the business dictionary, diagram, guarded and broken reports, your new cases and their results. Add a receiving note that separates proven scratch behavior from the next integration milestone.

Continue with the [transaction proof lab](/training/guides/financial-handoff) to exercise overlapping local writes, stale review and rollback using two real SQLite connections. The remaining remote-source and recovery contracts still need integration evidence.

## 5. Rehearse the mentor and receiving-owner review

Ask a peer or facilitator to run this 20-minute review. If working alone, record self-rehearsal. The Academy lesson coach can help prepare reasoning; the worksheet does not imply a scheduled human reviewer.

1. Explain why money being credited does not always mean the case is finished.
2. Demonstrate the unsupported final note in the deliberately broken run.
3. Let the reviewer change the source revision or retry payload. Predict the outcome.
4. Explain what happens when case and ledger evidence disagree.
5. Show the next receiving owner, stop condition and missing integration evidence.

Record the challenge, initial explanation, changed decision, actual evidence and unresolved work. The reviewer should be able to reproduce your proof without your narration.

Build a hypothetical value case around accepted handoffs. Include correction, reconciliation, review and operating costs. Faster drafting alone does not establish net value, and the course does not provide measured financial outcomes.

## 6. Sources and next practice

Original LockedIn Labs instruction, checked against these primary references on 22 October 2026:

- [CFPB: unauthorized transactions and temporary credit](https://www.consumerfinance.gov/ask-cfpb/how-do-i-get-my-money-back-after-i-discover-an-unauthorized-transaction-or-money-missing-from-my-bank-account-en-1017/).
- [CFPB: Regulation E error-resolution procedures](https://www.consumerfinance.gov/rules-policy/regulations/1005/11/). Applicability, exceptions and timing need the responsible policy owner's interpretation for the actual product and circumstances.

Continue with [the protected financial-services course](/app/academy?course=financial-services-operations&lesson=business-language&view=focus), or compare this workflow with [healthcare operations](/training/guides/healthcare-operations). The engineering discipline transfers; the business terminology and decision rights must be learned again.