User Stories and Acceptance Criteria: Fintech Examples

The standard format has three parts:

As a [type of user], I want [to do something], so that [I get some value].

Each part does a job. "As a" forces you to name a real user, not "the system". "I want" describes the behaviour, not the screen. "So that" states the value, which is what lets the team suggest a simpler way to deliver it. If you can't fill in "so that", question whether the story is needed.

The INVEST checklist is still the best quick test:

Acceptance criteria are the conditions a story must meet to be accepted. Written as scenarios, they read like small tests:

• Given the starting situation
• When the user does something
• Then the result you can check

Write the main success path first, then the unhappy paths: wrong input, missing data, limits, timeouts, permissions. In financial products the unhappy paths are where the money and the risk sit, so they deserve most of your attention.

The examples below are illustrations, written for this guide. They show the pattern, not any bank's actual requirements.

As a retail customer, I want to submit a treasury bill request online, so that I can invest without visiting a branch.

• Scenario: sufficient balance. Given the auction window is open and my balance covers the amount plus charges, when I submit a request, then the request is accepted and the amount plus charges is held on my account.
• Scenario: insufficient balance. Given my balance does not cover the amount plus charges, when I submit, then the request is rejected and I see how much more I need.
• Scenario: window closed. Given the auction window has closed, when I open the request page, then I can't submit, and I see when the next window opens.

Notice each scenario has one clear check. A tester can run it; a developer knows when they're done.

As a checker in operations, I want to approve or reject requests captured by a maker, so that no single person can complete a transaction alone.

• Scenario: approve. Given a request is awaiting approval, when I approve it, then its status changes to Approved and the maker is notified.
• Scenario: reject needs a reason. Given a request is awaiting approval, when I reject it without entering a reason, then the rejection is blocked until I add one.
• Scenario: no self-approval. Given I captured a request as maker, when I open the approval queue, then that request is not available for me to approve.

Controls like these come straight from how regulated finance works. The Treasury Management System case study shows maker-checker queues with comments, rejection reasons and notifications at every step.

As a mobile banking customer, I want to confirm a transfer with a one-time password, so that nobody else can send money from my account.

• Scenario: correct code. Given I've entered transfer details, when I enter the correct one-time password within its validity period, then the transfer is processed and I see a confirmation with a reference.
• Scenario: expired code. Given my one-time password has expired, when I enter it, then the transfer is not processed and I can request a new code.
• Scenario: repeated wrong codes. Given I've entered a wrong code the maximum number of times, when I try again, then the transfer is cancelled and I'm told what to do next.

Where the exact limits (validity period, number of attempts) come from a policy, reference the policy or the business rule in the story rather than inventing a number in the backlog.

As a customer, I want to withdraw my consent for an app to access my account data, so that I stay in control of who sees my information.

• Scenario: revoke. Given I've granted an app access to my account data, when I revoke that consent, then the app can no longer retrieve my data and I see the date access ended.
• Scenario: record kept. Given I've revoked consent, when the bank reviews the consent history, then the grant and the revocation are both recorded with dates.

Consent is at the centre of open banking, where customers let other providers access their account data through APIs. Stories like this need an audit record as well as a screen.

"As a customer, I want to apply for a loan" is an epic, not a story. Split it along one of these lines:

• By workflow step: capture details, upload documents, credit check, decision, disbursement.
• By business rule: salary loans first, then asset-backed loans.
• By path: the success path first, then each exception.
• By data: individual customers first, then corporate customers.
• By channel: mobile first, then web, then branch.

Each slice should still deliver something a user could notice.

1. "As the system, I want..." Systems don't want things. Find the user who benefits.
2. Criteria that describe the screen, not the behaviour. "A blue button at the top right" is design; "I can submit from the summary page" is behaviour.
3. Only the happy path. If there's no scenario for failure, the developer will decide what happens.
4. Untestable words. "Fast", "secure" and "user-friendly" can't be checked. Put measurable targets in non-functional requirements.
5. No link to a requirement. Every story should trace back to a business requirement, so you can prove coverage at UAT. BRD vs FRS vs user stories explains how they connect.