Your First Broker Go‑Live Shouldn’t Be a Surprise: 20 UAT Scenarios That Catch Deposit, Margin & Swap Failures

Launching a new brokerage is less about “does the platform run?” and more about “do all money and risk flows reconcile under stress?” Most go-live incidents come from edge cases: partial fills, weekend swaps, payment callbacks, or margin rules that behave differently across symbols and groups.

Below is a focused UAT pack you can run in a staging environment to validate the five failure-prone areas: deposits, margin, swaps, rejects, and withdrawals—from client portal → CRM/backoffice → trading server → bridge/LP (if applicable) → reporting.

1) Before you test: lock your UAT baseline (or results won’t mean anything)

UAT gets messy when configuration changes daily. Freeze a baseline for at least a week and document it so every “expected result” is testable and repeatable.

Minimum baseline to lock:

• Account groups (retail/pro, demo/real, region-based), leverage, margin mode, stop-out levels
• Symbol specs: contract size, tick size, swap type (points/percentage), triple-swap day, trading sessions
• Fees: commissions, markups, deposit/withdrawal fees, negative balance protection rules
• Payments: PSP credentials for sandbox, callback URLs, risk rules (velocity, country, BIN), manual review flags
• Integrations: CRM ↔ MT4/MT5/cTrader/MatchTrader, bridge/aggregator, risk backoffice, email/SMS

Tip: create three test personas (low-risk retail, high-volume scalper, and “problem user” that triggers compliance/payment flags). You’ll reuse them in every scenario.

2) Deposits UAT: prove the ledger, the trading balance, and the audit trail match

A deposit isn’t “successful” when the PSP says approved—it’s successful when every system agrees on: amount, currency, fees, timestamps, and balance impact.

Run these UAT scenarios end-to-end:

• Happy path (card/crypto/bank transfer): deposit approved → CRM wallet updates → trading balance updates → client sees it in portal → backoffice report matches.
• Callback order reversal: PSP sends callback before redirect completes (or duplicate callbacks). Expected: idempotency—one deposit credit, not two.
• Pending → Approved later (manual review): ensure no premature credit, and approval triggers the correct balance operation.
• Declined deposit: verify no balance movement, but the attempt is logged with reason codes (for ops + compliance).
• Chargeback/charge dispute simulation (where possible in sandbox): confirm you can freeze funds or apply a balance adjustment with a clear audit note.

What to validate each time:

• Client-facing receipt and internal transaction ID mapping
• Fee handling (gross vs net credit) and currency conversion logic
• Reporting: daily deposits report totals match PSP settlement view (even in sandbox logic)
• Permissioning: who can manually approve/void/edit, and whether changes are logged

3) Margin UAT: test “can open” vs “can survive” (and what happens at the edge)

Margin issues usually show up when volatility hits: prices gap, spreads widen, or multiple positions net against each other unexpectedly. Your UAT should cover both order entry checks and ongoing margin monitoring.

Core scenarios to run:

• Open at boundary: place an order that should pass with a small buffer (e.g., 101–105% of required margin). Confirm consistent behavior across platform and backoffice.
• Reject at boundary: place an order that should fail by a tiny amount. Expected: correct reject reason (not a generic “trade context busy”).
• Multi-symbol margin: open correlated positions (e.g., EURUSD + GBPUSD) and confirm margin is calculated per your group rules (hedged vs non-hedged, netting vs hedging accounts).
• Spread widening simulation: increase spread/markups in staging and watch margin level drop. Confirm alerts, stop-out logic, and any risk rules trigger correctly.
• Leverage change mid-life: change leverage (as ops would after a KYC tier change). Expected: positions remain consistent; margin recalculates; audit log records who/why.

Checks that prevent go-live pain:

• Stop-out behavior matches your policy (close order sequence, partial close rules)
• Negative balance protection (if enabled) behaves consistently and is reportable
• Risk backoffice and trading server show the same exposure and P&L inputs

4) Swaps UAT: validate the overnight engine (especially triple-swap and symbol sessions)

Swap mistakes create slow-burn trust issues: clients notice after days, then your support team drowns in tickets. UAT swaps like you’d test payroll: deterministic, documented, and reconciled.

Must-test swap scenarios:

• Standard overnight: hold a position across rollover; verify swap is applied once, at the correct time, with the expected sign (long vs short).
• Triple-swap day: hold across the configured triple day (often Wednesday for FX, but your setup may differ by symbol). Expected: exactly 3x the standard swap amount, not 2x or 4x.
• Weekend/holiday session edge: symbols with modified sessions—ensure swaps don’t apply when the market is closed in a way that contradicts your contract specs.
• Swap-free / Islamic group: confirm swaps are not applied, and any alternative admin fee (if you use one) is applied exactly as configured.
• Partial close and swap: open 1.0 lot, hold overnight, then partially close. Confirm swap allocation is correct and visible in history.

Reconciliation checklist:

• Trading history lines match backoffice statements
• Statement wording is client-friendly (avoid cryptic internal codes)
• You can explain swap math internally (ops runbook), even if you don’t expose formula details publicly

5) Rejects UAT: make sure every failure is “clean” (and support can diagnose it fast)

Rejects are inevitable. What matters is whether they’re predictable, correctly messaged, and logged with enough context to resolve disputes.

Test rejects across categories:

• Insufficient margin: message is explicit; no order is partially created; logs show required vs available.
• Invalid volume / step size: try volumes below min, above max, and off-step (e.g., 0.013). Expected: correct constraint enforcement.
• Off quotes / requotes / price changed: simulate fast market; confirm how your platform handles slippage and whether client sees a clear reason.
• Market closed: attempt trading outside sessions; ensure consistent behavior across mobile/web/desktop.
• Risk rules: trigger max lot, max positions, symbol restrictions, country restrictions (where applicable). Expected: deterministic rejects with a backoffice-visible rule hit.

Operational requirement: every reject should produce a support-ready record:

• Timestamp, symbol, requested price, executed price (if any), IP/device (where captured)
• Rule or constraint that caused the reject
• Linkable IDs between CRM ticketing, platform logs, and (if used) bridge execution logs

6) Withdrawals UAT: prove controls, SLAs, and “stuck money” recovery paths

Withdrawals are where compliance, payments, and support collide. Your UAT should confirm not only the happy path, but what happens when withdrawals are paused, reversed, or partially paid.

Run these scenarios:

• Standard withdrawal: request → compliance checks → approval → PSP payout → status updates back to portal/CRM.
• Withdrawal while margin is tight: client has open positions; confirm your policy is enforced (free margin checks, equity rules, or blocking logic).
• Partial withdrawal: request more than available free balance (after fees/bonuses). Expected: clear rejection or adjusted allowable amount.
• Manual review hold: trigger AML/velocity flags; confirm the case is queued correctly and client messaging doesn’t overpromise timelines.
• Reversal / failed payout: PSP fails payout; ensure funds are returned to wallet/balance correctly with a transparent audit trail.

Controls to validate (and align with local regulations):

• Role-based approvals (maker/checker), limits by amount and payment method
• Proof-of-ownership checks (where required), and how evidence is stored
• Accurate client notifications (status changes) without exposing sensitive risk logic

The Bottom Line

Go-live readiness isn’t a single “UAT passed” checkbox—it’s confidence that money movements, margin logic, and overnight charges behave correctly in real-world edge cases.

If you test deposits, margin, swaps, rejects, and withdrawals with the scenarios above—and insist on clean logs and reconciliation—you’ll prevent the most common launch-day incidents.

When you’re ready to turn this into a repeatable go-live runbook, start here: /get-started.