# 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 - Document current payment silos, volumes and costs - Interview channel, operations and compliance stakeholders - Define hub objectives and measurable benefits - Agree scope, channels, currencies and rails ### Requirements and Process Design - Write business requirements for initiation and validation - Design processing stages and state model - Define routing rules for each rail and currency - Map exception handling and repair workflows ### Architecture and Integration Design - Define hub components and microservice boundaries - Design integrations with core banking and screening - Specify API contracts for channels and corporates - Agree data model, security and resilience design ### Build Support - Support developers during hub build and integration - Create test data for domestic and cross-border payments - Support API testing with channel teams - Track defects and update requirements where needed ### Testing and Certification - Create UAT scenarios for each payment type and rail - Support performance, security and disaster recovery testing - Run scheme certification with clearing systems - Obtain business sign off for each release ### Cutover and Go Live - Plan phased migration of payment types to the hub - Prepare operations runbooks and training material - Support hypercare and monitor hub performance - Hand over to operations and close the project ## 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: - Executive Summary - Business Objectives and Scope - Payment Types, Channels and Currencies - Current State and Pain Points - Target State Hub Capabilities - Business Rules and Controls - Stakeholders and RACI - Risks, Assumptions and Sign Off ### 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: - Introduction and Scope - Hub Architecture and Interfaces - Processing Stages and State Model - Routing and Screening Rules - Limits, Fees and FX Rules - Exception and Reversal Handling - Status Reporting and Notifications - Non Functional Requirements ### 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: - Process Overview and Scope - Actors and Swimlanes - Initiation and Validation Flow - Routing and Screening Flow - Clearing and Settlement Flow - Exception and Recall Paths - Controls and Handoffs - Timing and Cutoffs ### 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: - Architecture Overview - Component and Service Design - Integration Pattern and Message Flow - Data Architecture and Storage - Security and Access Control - Resilience, Performance and Scalability - Deployment and Environments - Risks and Design Decisions ### 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: - Mapping Overview and Conventions - Channel to Hub Field Mapping - Hub to Core Banking Mapping - Hub to Clearing Mapping - Hub to Ledger Mapping - Validation Rules per Field - Transformation and Default Rules - Version History ### 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: - API Overview and Principles - Authentication and Authorisation - Endpoint Catalogue - Request and Response Payloads - Error Codes and Handling - Idempotency and Duplicate Prevention - Performance and Rate Limits - Versioning and Change Control ### 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: - Epic and Story Structure - Story: Payment Initiation - Story: Validation and Routing - Story: Screening Integration - Story: Clearing and Settlement - Story: Exception Handling - Story: Reporting and Reconciliation - Definition of Done ### 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: - Acceptance Criteria Principles - Criteria per User Story - Validation and Routing Criteria - Screening and Settlement Criteria - Performance Criteria - Security and Audit Criteria - UAT Entry and Exit Criteria - Sign Off Checklist ### 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: - UAT Scope and Approach - Test Environment and Data - Scenario: Domestic Payment - Scenario: Cross-Border Payment - Scenario: Duplicate and Timeout - Scenario: Sanction Hit and Repair - Scenario: Bulk File and Reversal - Defect Management and Sign Off ### 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: - Traceability Principles - BRD to FSD Mapping - FSD to User Story Mapping - User Story to Test Case Mapping - Test Case to UAT Result Mapping - Coverage Summary - Open Items and Gaps - Sign Off