Payments Training Hub

Capstone Projects › Build a Payment Hub

Build a Payment Hub

Design a single platform that validates, screens, routes and settles every payment type

This project builds a central payment hub that replaces separate silos for domestic, cross-border, instant and bulk payments with a single platform. The hub receives a payment from any channel, validates the instruction, checks limits and funds, screens it for sanctions and fraud, routes it to the best rail, and reports its status in real time. A 5,000 dollar Faster Payments transfer in the UK, a 20,000 euro SEPA credit transfer and a 100,000 dollar cross-border payment through SWIFT all flow through the same stages, with rail specific rules applied at routing. The business analyst writes the business requirements, designs the processing stages and routing rules, defines the screening and exception integrations, and specifies the API contracts that channels and corporates use to connect to the hub.

Phases

Discovery and Business Case

Requirements and Process Design

Architecture and Integration Design

Build Support

Testing and Certification

Cutover and Go Live

Deliverables

BRD

The Business Requirements Document states what the business needs from a central payment hub, including the payment types, channels, currencies and rails it must support. It covers initiation from branches, internet banking, mobile apps and corporate file uploads, and it defines the business rules for routing, screening, pricing, limits and exception handling. It is the single source of business truth that technology, operations and compliance sign off before design and build start.

Template sections:

FSD

The Functional Specification Document describes how the payment hub must behave at each processing stage, from initiation and validation through routing, screening, clearing and settlement. It defines the rules for duplicate detection, limit checks, FX conversion, fee calculation and status reporting, and it states the behaviour for timeouts, rejections and reversals. Developers and testers use it as the precise specification for build and test.

Template sections:

Process Flow

The Process Flow shows the end to end journey of a payment through the hub, from channel initiation to beneficiary credit, with swimlanes for the customer, the channel, the hub, compliance and the clearing system. It shows decision points for validation, screening and routing, and the exception paths for repair, rejection and recall. Operations teams use it to understand the new process and to train staff.

Template sections:

Solution Architecture

The Solution Architecture describes the hub technology design, including microservices for initiation, validation, routing, screening and settlement, the message queue, the database and the integration layer. It shows how the hub connects to the core banking system, the SWIFT interface, the sanctions screening engine, the fraud platform and each clearing system. It covers resilience, scalability, security and disaster recovery, and it guides the build team.

Template sections:

Data Mapping Sheet

The Data Mapping Sheet lists every field that flows into and out of the hub, from the channel payload to the core banking record, the clearing message and the ledger entry. It shows the source, the target, the data type, the transformation rule and the validation rule for each field, including party, account, amount, currency, value date and charges. It is the reference that developers and testers use to build and verify every interface.

Template sections:

API Specification

The API Specification defines the hub application programming interfaces for payment initiation, payment status, bulk file upload and webhook notifications. It lists each endpoint, the request and response payloads, the authentication method using OAuth 2.0, the error codes, the idempotency key handling and the service levels for response time and availability. It lets channel teams and corporate clients integrate with the hub safely.

Template sections:

Jira User Stories

Jira User Stories break the hub build into small, deliverable pieces that a development team can complete in a sprint. Each story states the user need, the business value and the acceptance criteria, and it is linked to the BRD, the FSD and the data mapping sheet. Stories cover initiation, validation, routing, screening, settlement, exception handling and reporting, with clear priorities, dependencies and a definition of done.

Template sections:

Acceptance Criteria

Acceptance Criteria define the conditions that must be met before a hub feature or release is accepted by the business. Each criterion is specific, measurable and testable, and it states the expected result for a given payment, including validation, routing, screening, settlement and status reporting. Criteria are agreed before development starts and are used as the basis for user acceptance testing, performance testing and production sign off.

Template sections:

UAT Scenarios

UAT Scenarios describe the business tests that prove the hub works end to end, from a 5,000 dollar domestic payment to a 100,000 euro cross-border payment. Each scenario states the precondition, the test steps, the input, the expected output and the evidence required. Scenarios cover standard payments, duplicate submissions, sanction hits, insufficient funds, timeouts, reversals and bulk file uploads, so the business can sign off with confidence.

Template sections:

RTM

The Requirements Traceability Matrix links every hub requirement in the BRD to its functional specification, its design component, its user story, its test case and its UAT result. It shows which requirements are covered, which are in progress and which have failed testing, so that no requirement is lost during the build. It is the main evidence that the hub meets the agreed scope and is ready for production release.

Template sections:

← Back to all capstones Download brief (p2.md)