BA / PO Practical Labs
10 hands-on labs. Each one walks through a real BA or PO task, step by step, with templates and a worked example. Do the lab, produce the deliverable, and you have evidence of the skill, not just a chapter read.
LAB-01: Write Requirements for Same-Day Cross-Border Payments for SMEsA mid-sized bank wants to offer same-day cross-border payments to its small and medium enterprise customers, who today wait two to three days for supplier payments to arrive. The current process relies on manual checks, emailed instructions and a correspondent chain that the customer cannot track. In this lab you act as the business analyst who turns that business problem into a clear, testable set of requirements. You will define the objectives and the scope, identify the stakeholders, record the assumptions and dependencies, and write the business rules that govern cutoffs, charges and value dates. You will then separate functional requirements from non-functional requirements, so that the development team knows what the solution must do and how well it must do it. By the end of the lab you will have a requirements pack that a sponsor can sign off and a development team can build from without guessing.
LAB-02: Redesign the Payment Exception Repair ProcessWhen a payment cannot be processed straight through, it lands in an exception queue where operations staff must repair it, return it or reject it. In many banks that queue is slow, opaque and full of rework, because nobody has mapped the process end to end. In this lab you model the as-is exception repair process, measure where time is lost, and design a to-be process that clears most exceptions on first touch. You will draw a BPMN diagram with clear swimlanes, add sequence diagrams for the system interactions, and model the exception flows for the most common failure types. You will also define the controls, the handoffs and the service levels for each step. By the end of the lab you will have a process design that operations can run, technology can build, and management can measure.
LAB-03: Map MT103 to pacs.008 for a MigrationMigrating from MT103 to pacs.008 is a data exercise before it is a technology exercise, and the quality of the mapping decides whether payments arrive intact. In this lab you build a source-to-target mapping for a real migration scope, starting from a canonical data model and working down to field level rules. You will decide which fields are mandatory, optional or defaulted, write the transformation rules for party data, addresses, remittance information and charges, and define the validation rules that catch bad data before it leaves the bank. You will also record data lineage, so that any field in the outgoing pacs.008 can be traced back to its source. By the end of the lab you will have a mapping sheet that developers can build from and testers can verify against.
LAB-04: Specify a Payment Initiation API for a Corporate ChannelA corporate banking channel needs an API that lets treasury systems initiate payments directly, without a person typing each instruction into a screen. The API must be easy to integrate, safe against duplicate payments, and clear about what went wrong when a request fails. In this lab you analyse and specify a payment initiation API from the business need down to the contract. You will define the endpoints, the HTTP methods, the request and response schemas, the authentication model, the error codes, and the rules for idempotency, correlation IDs, timeouts and retries. You will also write the OpenAPI contract that the corporate integration team builds against. By the end of the lab you will have an API specification that is complete enough to hand to a developer and a corporate customer without a follow-up meeting.
LAB-05: Deliver an Instant Payments Feature in Three SprintsAn instant payments feature must reach customers in weeks, not months, and the work must be split into pieces that a team can build, test and release in short sprints. In this lab you plan and run the delivery of an instant payments feature across three two-week sprints. You will break an epic into features and user stories, write acceptance criteria in plain language and in Gherkin, build and prioritise the backlog, and plan the sprint goals, the stand-ups, the reviews and the retrospectives. You will also define the RACI for the release and the definition of done that decides when a story is truly finished. By the end of the lab you will have a delivery plan that a product owner, a scrum master and a development team can execute together.
LAB-06: Write a UAT Plan for a Payment Hub Go-LiveA payment hub go-live is a moment when a testing gap becomes a customer problem within minutes, so the user acceptance test must be thorough, realistic and well organised. In this lab you write the UAT plan for a payment hub go-live, covering system integration testing, user acceptance testing, reconciliation and production validation. You will design happy path, negative, boundary, integration and regression scenarios, plan the defect triage process, and define the entry and exit criteria that decide whether the hub is ready. You will also prepare the reconciliation checks that prove every payment reached the right ledger. By the end of the lab you will have a test plan that the business can sign off with confidence and the test team can execute without improvisation.
FLOW-01: Deliver a Cross-Border Correspondent Payment in US DollarsA corporate customer in London needs to pay a supplier in New York in US dollars, and the bank must move the money through correspondent banks, apply the agreed foreign exchange rate, deduct the correct charges, and settle on the agreed value date. Today the process depends on manual checks, emailed instructions, and a chain of intermediaries that the customer cannot see, so payments are slow, expensive, and hard to explain when they arrive late or short. In this lab you act as the business analyst for the full flow. You will compare the serial method, where the payment instruction travels with the funds through each correspondent, with the cover method, where the instruction travels directly and the funds settle separately. You will define the routing, the charge bearer options, the foreign exchange rules, the cutoffs, and the settlement steps. You will also define how the bank reports status, handles repairs, and reconciles the nostro account. By the end you will have a complete pack that operations, treasury, compliance, and technology can all use.
FLOW-02: Deliver an Instant Payment with Timeout and Duplicate ControlsA retail customer sends money from a mobile app and expects it to arrive in seconds, at any hour, with a clear confirmation on screen. Behind that simple tap sits a tight chain: real time validation of the account, the limits, and the funds, sanctions screening in seconds, a liquidity check, settlement with the clearing system, and a confirmation back to the sender. If any link is slow, the payment must time out safely, and if the customer taps twice, the payment must never be sent twice. In this lab you act as the business analyst for the full instant payment flow. You will define the validation rules, the timeout limits, the duplicate prevention controls, the settlement steps, and the confirmation and failure messages. You will also define the liquidity, reconciliation, and 24 hour support requirements. By the end you will have a complete pack that the product team, technology, operations, and risk can build, test, and run.
FLOW-03: Deliver a Card Payment from Authorisation to DisputeA customer pays with a card in a shop or online, and the money must move through authorisation, clearing, settlement, and reconciliation, with refunds and disputes handled fairly when things go wrong. The shop needs a fast answer at the till, the cardholder needs a clear statement, the merchant needs to be paid on time, and the bank needs to match every transaction to its ledger. You will also learn how the bank proves each transaction was authorised, cleared, and settled correctly. In this lab you act as the business analyst for the full card payment flow. You will define the authorisation checks, the clearing file exchange, the settlement timing, the fee and interchange rules, and the reconciliation checks. You will also define the refund flow, the chargeback flow, and the evidence each party must provide in a dispute. By the end you will have a complete pack that the cards team, operations, finance, risk, and technology can build, test, and run.
FLOW-04: Reconcile Payments Across Messages, Statements, and LedgerEvery payment leaves a trail in several places: the payment message, the nostro statement, the clearing record, the settlement record, and the ledger. When those records agree, the bank can close the day with confidence. When they disagree, the difference is a break that must be found, explained, and fixed before it affects a customer or a financial report. You will also learn how to prove that every payment was accounted for, even when the source systems disagree about the amount, the date, or the reference. In this lab you act as the business analyst for the full reconciliation flow. You will define the matching rules, the tolerances for fees and foreign exchange, and the handling of missing, duplicate, and partial matches. You will design the break workflow, the ageing and escalation rules, and the reports that finance and operations use each day. By the end you will have a complete pack that finance, operations, treasury, audit, and technology can use to run daily reconciliation with confidence.