Simulation

Simulation

Simulation endpoints are sandbox-only tools that let you drive application review states on demand — no need to wait for a real FV Bank reviewer. Most of them also fire the matching lifecycle webhook so you can test handlers end-to-end. /simulate/sanction-status and /simulate/risk-status set a verdict only and fire no webhook. /simulate/create-account is different: it performs the real account-opening request (no supervisor right required) and a real account follows.

All simulate endpoints return 400 in production — they are disabled outside the sandbox.

---

Key concepts

• Status codes — 2 = Missing, 3 = Approved, 4 = Rejected. All status endpoints use the same values.
• IDs — Each endpoint needs the ID of the item being simulated. Retrieve them from GET /application/detail/{id}.
• Remark field — The comment endpoint sends its text in Remark. Optional on the status endpoints.
• No webhook — sanction and risk simulations do not emit events. Confirm the result with GET /application/detail/{id}.
• Sticky override — sanction and risk statuses are stamped with a broker-override marker (statusUpdatedBy prefixed b_) and are not recomputed afterward. A re-submit can create a new screening record, which is not covered by the previous override.
• Create account — /simulate/create-account is a one-way door: the application locks at Account Requested and further broker submits are rejected. A 200 means the request was accepted, not that the account exists. Poll AccountOpeningStatus on application detail, or wait for account.created.

---

Common workflows

Test approval

1. POST /simulate/form-status with Status 3 — fires form.approved.
2. Verify your webhook handler receives and processes the event.

Test document rejection and re-upload

1. POST /simulate/document-status with Status 4 — fires document.rejected.
2. Re-upload the corrected file.
3. POST /simulate/document-status with Status 3 — fires document.approved.

Test the ask flow

1. POST /simulate/ask-created — fires ask.created (typically followed by form.missing) and adds an open ask to the application.
2. GET /application/detail/{id} — find the new ask in the Asks list.
3. POST /application/ask/answer — submit the answer.

Test KYC approval

1. The applicant completes KYC first (dummy values are fine) until the system concludes approved or rejected.
2. GET /application/detail/{id} — find the individual/UBO ID in Kyc[].IndividualId.
3. POST /simulate/kyc-status with IndividualId and Status: 3 — fires kyc.approved (sandbox only).

Test a reviewer comment

POST /simulate/comment-added with Id (ApplicationId) and a Remark — fires comment.created to your webhook.

Test a sanctions verdict

1. Complete KYC first so screening has run (the simulator returns 400 otherwise).
2. POST /simulate/sanction-status with Status 3 — sets the business-name screening. Pass IndividualId to target that individual's screening instead.
3. No webhook is sent. Confirm the result with GET /application/detail/{id}.

Test a risk verdict

1. POST /simulate/risk-status with Status 3 — sets the risk assessment. No webhook is sent.
2. Confirm with GET /application/detail/{id}. Without this call, risk can pass on its own once every other step is past draft.

Test account opening

1. Approve every step first — form, documents, KYC, sanctions, and risk. A business application also needs a Certificate of Incorporation with a usable attachment.
2. POST /simulate/create-account with the application Id. The application moves to Account Requested and locks.
3. A 200 means the request was accepted, not that the account exists. Poll AccountOpeningStatus on GET /application/detail/{id}, or wait for the account.created webhook. A failed creation stays requested and is picked up by an FV Bank agent; nothing is signalled to the broker.