Payments Academy
Discovery workshop brings stakeholders together PAYMENT OPERATIONS STARTED LIVE 01 Discovery workshop - all the stakeholders into one room ACTIVE 02 Workshop facilitation discipline - analyst facilitates the workshop QUEUED 03 Conflicting requirements - normal in payments QUEUED 04 Prioritisation - everyone in the room can use. QUEUED 05 Workshop - set of outputs, not with a vague sense QUEUED 06 Sign-off - turns workshop outputs into a baseline. QUEUED A discovery workshop brings all the stakeholders into one room Step 1 of 6 Discovery workshop brings stakeholders together STARTED Discovery workshop all the stakeholders into one room ACTIVE Workshop facilitation discipline analyst facilitates the workshop QUEUED Conflicting requirements normal in payments QUEUED Prioritisation everyone in the room can use. QUEUED Workshop set of outputs, not with a vague sense QUEUED Sign-off turns workshop outputs into a baseline. QUEUED A discovery workshop brings all the stakeholders into one room
Workshop facilitation discipline PAYMENT OPERATIONS IN PROGRESS LIVE 01 Discovery workshop - all the stakeholders into one room DONE 02 Workshop facilitation discipline - analyst facilitates the workshop ACTIVE 03 Conflicting requirements - normal in payments QUEUED 04 Prioritisation - everyone in the room can use. QUEUED 05 Workshop - set of outputs, not with a vague sense QUEUED 06 Sign-off - turns workshop outputs into a baseline. QUEUED The analyst facilitates the workshop, which means keeping the discussion on track, making sure every voice is heard, and preventing any one person from dominating. Step 2 of 6 Workshop facilitation discipline IN PROGRESS Discovery workshop all the stakeholders into one room DONE Workshop facilitation discipline analyst facilitates the workshop ACTIVE Conflicting requirements normal in payments QUEUED Prioritisation everyone in the room can use. QUEUED Workshop set of outputs, not with a vague sense QUEUED Sign-off turns workshop outputs into a baseline. QUEUED The analyst facilitates the workshop, which means keeping the discussion on track, making sure every voice is heard, and preventing any one person from dominating.
Conflicting requirements PAYMENT OPERATIONS IN PROGRESS LIVE 01 Discovery workshop - all the stakeholders into one room DONE 02 Workshop facilitation discipline - analyst facilitates the workshop DONE 03 Conflicting requirements - normal in payments ACTIVE 04 Prioritisation - everyone in the room can use. QUEUED 05 Workshop - set of outputs, not with a vague sense QUEUED 06 Sign-off - turns workshop outputs into a baseline. QUEUED Conflicting requirements are normal in payments, because different teams optimise for different things. Step 3 of 6 Conflicting requirements IN PROGRESS Discovery workshop all the stakeholders into one room DONE Workshop facilitation discipline analyst facilitates the workshop DONE Conflicting requirements normal in payments ACTIVE Prioritisation everyone in the room can use. QUEUED Workshop set of outputs, not with a vague sense QUEUED Sign-off turns workshop outputs into a baseline. QUEUED Conflicting requirements are normal in payments, because different teams optimise for different things.
Prioritisation: handled with simple framework PAYMENT OPERATIONS IN PROGRESS LIVE 01 Discovery workshop - all the stakeholders into one room DONE 02 Workshop facilitation discipline - analyst facilitates the workshop DONE 03 Conflicting requirements - normal in payments DONE 04 Prioritisation - everyone in the room can use. ACTIVE 05 Workshop - set of outputs, not with a vague sense QUEUED 06 Sign-off - turns workshop outputs into a baseline. QUEUED Prioritisation is handled with a simple framework that everyone in the room can use. Step 4 of 6 Prioritisation: handled with simple framework IN PROGRESS Discovery workshop all the stakeholders into one room DONE Workshop facilitation discipline analyst facilitates the workshop DONE Conflicting requirements normal in payments DONE Prioritisation everyone in the room can use. ACTIVE Workshop set of outputs, not with a vague sense QUEUED Sign-off turns workshop outputs into a baseline. QUEUED Prioritisation is handled with a simple framework that everyone in the room can use.
Workshop ends with clear outputs PAYMENT OPERATIONS IN PROGRESS LIVE 01 Discovery workshop - all the stakeholders into one room DONE 02 Workshop facilitation discipline - analyst facilitates the workshop DONE 03 Conflicting requirements - normal in payments DONE 04 Prioritisation - everyone in the room can use. DONE 05 Workshop - set of outputs, not with a vague sense ACTIVE 06 Sign-off - turns workshop outputs into a baseline. QUEUED The workshop ends with a clear set of outputs, not with a vague sense of agreement. Step 5 of 6 Workshop ends with clear outputs IN PROGRESS Discovery workshop all the stakeholders into one room DONE Workshop facilitation discipline analyst facilitates the workshop DONE Conflicting requirements normal in payments DONE Prioritisation everyone in the room can use. DONE Workshop set of outputs, not with a vague sense ACTIVE Sign-off turns workshop outputs into a baseline. QUEUED The workshop ends with a clear set of outputs, not with a vague sense of agreement.
Sign-off: formal step PAYMENT OPERATIONS COMPLETE LIVE 01 Discovery workshop - all the stakeholders into one room DONE 02 Workshop facilitation discipline - analyst facilitates the workshop DONE 03 Conflicting requirements - normal in payments DONE 04 Prioritisation - everyone in the room can use. DONE 05 Workshop - set of outputs, not with a vague sense DONE 06 Sign-off - turns workshop outputs into a baseline. ACTIVE Sign-off is the formal step that turns workshop outputs into a baseline. Step 6 of 6 Sign-off: formal step COMPLETE Discovery workshop all the stakeholders into one room DONE Workshop facilitation discipline analyst facilitates the workshop DONE Conflicting requirements normal in payments DONE Prioritisation everyone in the room can use. DONE Workshop set of outputs, not with a vague sense DONE Sign-off turns workshop outputs into a baseline. ACTIVE Sign-off is the formal step that turns workshop outputs into a baseline.

Key points of this lesson, in order.

0:00 / 3:32 Step 1 of 6

Workshop Facilitation: Running a Payments Discovery Workshop

BA Practical Workshop, Lesson 7 of 7, Narration 3:32, D14 Business analysis and professional practice

ReconciliationCaptureCut-off

What you will learn

Your objective. By the end of this lesson, you will be able to explain workshop facilitation: running a payments discovery workshop. A discovery workshop brings all the stakeholders into one room, or one video call, for a focused session to agree on requirements, and it is the fastest way to resolve the questions that stall a payments project.

Why it matters. The analyst plans the workshop like any other deliverable.

Chapter objective: Learner applies business analysis techniques to a payments project, writing requirements, user stories, acceptance criteria, and a traceability matrix for a real payment feature. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Discovery workshop brings stakeholders together
  • Workshop facilitation discipline
  • Conflicting requirements
  • Prioritisation: handled with simple framework
  • Workshop ends with clear outputs
  • Sign-off: formal step

Key terms

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

Capture: The step in a card transaction where the merchant collects the authorised amount from the issuer, usually when goods are shipped.

Cut-off: The latest time a bank or payment system accepts a payment instruction for processing on a given value date.

Clearing and settlement timeline showing Workshop Facilitation: Running a Payments Discovery Workshop.

Insights and practice scenarios

Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.

Practise this lesson

Exercise

Route the payment described in this lesson and justify the route.

Use the routing rules, the correspondent chain and the charges in this lesson.

  1. What to do. Name each bank in the chain, the message used on each leg, and the charges deducted at each step.

Correct result. The route follows the correspondent chain from the debtor agent to the creditor agent, with each intermediary deducting its charge and passing the remainder on. The message on each leg carries the information the next bank needs.

Why. Routing is a business decision with a cost. The wrong route is slower, more expensive, or fails.

Check your understanding

Practice question

Which of the following best describes workshop facilitation: running a payments discovery workshop?

Takeaway and next step

What to remember

This discipline protects the project from endless rework, and it protects the analyst, because the signed document is the record of what was agreed and by whom.

Map the message fields from this lesson in the mapping workbench.

Open the Mapping Workbench →

Builds on "BRD and FSD Documents for Payments".

Transcript and full text

Show transcript

A discovery workshop brings all the stakeholders into one room, or one video call, for a focused session to agree on requirements, and it is the fastest way to resolve the questions that stall a payments project. The analyst plans the workshop like any other deliverable. A clear objective, a timed agenda, a list of decisions that must be made, and pre-reading sent two days in advance. A typical half-day agenda covers the As-Is process in the first hour, the pain points in the second, the To-Be process in the third, and the decisions and actions in the final thirty minutes. The analyst facilitates the workshop, which means keeping the discussion on track, making sure every voice is heard, and preventing any one person from dominating. A practical technique is to give each participant a fixed turn to speak, and to capture every point on a visible board so people can see their input recorded. When the conversation drifts into technical detail, the analyst parks the point in a list of open items and returns to the agenda. When two participants disagree, the analyst restates both positions neutrally and asks what evidence would settle the question. Conflicting requirements are normal in payments, because different teams optimise for different things. Operations may want a 2 in the afternoon cut-off so the team can finish reconciliation by 5 in the afternoon, while the business team wants a 5 in the afternoon cut-off to win corporate customers. The analyst does not choose a side, but frames the trade-off with data. Moving the cut-off to 5 in the afternoon adds 8,000 payments a day and requires two extra staff, while keeping it at 2 in the afternoon loses an estimated 40 corporate accounts a year. Presenting the trade-off in numbers lets the sponsor decide on facts rather than on who argued loudest. Prioritisation is handled with a simple framework that everyone in the room can use. The MoSCoW method sorts requirements into Must have, Should have, Could have and Will not have this time. A must-have for a UPI integration is the ability to raise a collect request; a should-have is the merchant dashboard; a could-have is a downloadable monthly report; and a will-not-have is support for recurring mandates in the first release. The workshop agrees the classification for every requirement, which stops scope creep later when someone asks for a could-have to be treated as a must-have. The workshop ends with a clear set of outputs, not with a vague sense of agreement. The analyst produces a decision log recording each decision, who made it and when, an action list with owners and dates, and a draft requirements list with the agreed priorities. These are circulated within 24 hours while the discussion is still fresh in everyone's mind. Participants have two working days to raise corrections, and silence after that period is treated as agreement, which prevents the workshop's decisions from being reopened weeks later. Sign-off is the formal step that turns workshop outputs into a baseline. The analyst sends the requirements document to the business sponsor, the operations head, the compliance lead and the IT architect, and each one signs to confirm that the document reflects what was agreed. Once signed, the requirements are frozen for the current release, and any change needs a change request with an impact assessment. This discipline protects the project from endless rework, and it protects the analyst, because the signed document is the record of what was agreed and by whom.

A discovery workshop brings all the stakeholders into one room, or one video call, for a focused session to agree on requirements, and it is the fastest way to resolve the questions that stall a payments project. The analyst plans the workshop like any other deliverable. A clear objective, a timed agenda, a list of decisions that must be made, and pre-reading sent two days in advance. A typical half-day agenda covers the As-Is process in the first hour, the pain points in the second, the To-Be process in the third, and the decisions and actions in the final thirty minutes.

The analyst facilitates the workshop, which means keeping the discussion on track, making sure every voice is heard, and preventing any one person from dominating. A practical technique is to give each participant a fixed turn to speak, and to capture every point on a visible board so people can see their input recorded. When the conversation drifts into technical detail, the analyst parks the point in a list of open items and returns to the agenda. When two participants disagree, the analyst restates both positions neutrally and asks what evidence would settle the question.

Conflicting requirements are normal in payments, because different teams optimise for different things. Operations may want a 2 in the afternoon cut-off so the team can finish reconciliation by 5 in the afternoon, while the business team wants a 5 in the afternoon cut-off to win corporate customers. The analyst does not choose a side, but frames the trade-off with data. Moving the cut-off to 5 in the afternoon adds 8,000 payments a day and requires two extra staff, while keeping it at 2 in the afternoon loses an estimated 40 corporate accounts a year. Presenting the trade-off in numbers lets the sponsor decide on facts rather than on who argued loudest.

Prioritisation is handled with a simple framework that everyone in the room can use. The MoSCoW method sorts requirements into Must have, Should have, Could have and Will not have this time. A must-have for a UPI integration is the ability to raise a collect request; a should-have is the merchant dashboard; a could-have is a downloadable monthly report; and a will-not-have is support for recurring mandates in the first release. The workshop agrees the classification for every requirement, which stops scope creep later when someone asks for a could-have to be treated as a must-have.

The workshop ends with a clear set of outputs, not with a vague sense of agreement. The analyst produces a decision log recording each decision, who made it and when, an action list with owners and dates, and a draft requirements list with the agreed priorities. These are circulated within 24 hours while the discussion is still fresh in everyone's mind. Participants have two working days to raise corrections, and silence after that period is treated as agreement, which prevents the workshop's decisions from being reopened weeks later.

Sign-off is the formal step that turns workshop outputs into a baseline. The analyst sends the requirements document to the business sponsor, the operations head, the compliance lead and the IT architect, and each one signs to confirm that the document reflects what was agreed. Once signed, the requirements are frozen for the current release, and any change needs a change request with an impact assessment. This discipline protects the project from endless rework, and it protects the analyst, because the signed document is the record of what was agreed and by whom.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.