Test an instant deposit crediting buying power

The contract this flow keeps

Two balances are in play and they are supposed to diverge, which is what makes this flow easy to get wrong.

• Buying power - starts at $250.00 and has to reach $750.00 after a $500.00 deposit.
• Settled cash - also $250.00 at the start, and is the figure that does not move instantly.
• The confirmation - states the amount is instantly available and names both the old and new buying power.
• The history - a deposit record with an id and the amount.

Asserting both balances at the start is what makes the test meaningful. Buying power and settled cash beginning at the same figure is exactly the condition under which a bug that moves the wrong one goes unnoticed.

The objective in plain English

The confirmation assertion includes the transition itself, from $250.00 to $750.00, rather than only the resulting figure, so the deposit is tied to the movement it caused.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/robinhood-clone-app/transfers?reset=true
max_steps: 40
tags: [robinhood, fintech, funding]
---

# Robinhud 16.4: Instant deposit

Catalog objective: initiate a deposit and verify the instant buying power credit.
Key assertion: buying power increases by the deposit amount.

## Verify the starting buying power
Verify "Buying power" reads "$250.00" and "Settled cash" reads "$250.00".

## Deposit from the bank
Type "500" into "Amount" and click "Deposit".

## Verify the instant credit
Verify a green banner titled "Deposit initiated" says "$500.00" is instantly available and buying power went from $250.00 to "$750.00".

## Verify the balance and the history
Verify "Buying power" now reads "$750.00" and the deposit history lists "DEP-501" for "$500.00".

The deposit history is checked separately from the balance because they are different records, and a credit applied without a corresponding history entry is an audit gap.

Assertion by assertion

A baseline, an action, and two independent confirmations.

The history record is what an operations team reconciles against later. A balance that moves without one is the kind of discrepancy that takes days to explain.

Putting it in CI

kane-cli testmd run tests/robinhood/instant-deposit_test.md

Add a variant that deposits above the instant limit, since the interesting behaviour is where the instant credit stops and a hold begins.

Funding flows gate everything downstream, which makes them a sensible early check in a suite. Kane CLI as a QA agent covers ordering a suite that way, and evidence based QA covers keeping proof of a balance change.