Capstone Projects › Implement an Instant Payment Solution
Implement an Instant Payment Solution
Settle in seconds, 24 hours a day, with real time validation and confirmation
This project implements an instant payment solution that settles in seconds, 24 hours a day, across UPI in India, SCT Inst in Europe, Faster Payments in the UK and FedNow in the United States. A 250 dollar UPI payment, a 2,000 euro SCT Inst payment and a 5,000 dollar FedNow payment must all complete within 10 seconds, including validation, sanctions screening and settlement, with a clear confirmation to the sender. The business analyst selects the rail for each market, designs initiation and real time validation, defines timeout and duplicate prevention rules, and specifies settlement, confirmation and operational service levels. The project covers liquidity management, 24 by 7 support, fraud monitoring and scheme certification, and it ends with a controlled launch and hypercare.
Phases
Rail Selection and Market Analysis
- Compare UPI, SCT Inst, Faster Payments and FedNow
- Assess limits, timelines, costs and certification needs
- Agree target markets, currencies and customer segments
- Define business case and launch priorities
Initiation and Validation Design
- Design initiation from mobile, internet and corporate channels
- Define real time validation for account, limits and funds
- Specify verification of payee and confirmation of payee
- Design customer confirmation and status screens
Real Time Processing Design
- Define screening within the 10 second timeline
- Design timeout, duplicate and idempotency rules
- Specify settlement and liquidity management
- Define return, recall and reversal workflows
Requirements and API Design
- Write the BRD and FSD with business and functional rules
- Specify APIs for initiation, status and request for payment
- Define SLAs for availability, response time and support
- Agree non functional requirements for resilience and audit
Build Support and Testing
- Support developers during real time engine build
- Create UAT scenarios for timeout, duplicate and sanction cases
- Support scheme certification with each clearing system
- Track defects and update requirements where needed
Launch and Hypercare
- Plan phased launch by market and customer segment
- Prepare 24 by 7 operations runbooks and training
- Monitor settlement times and success rates in hypercare
- Hand over to operations and close the project
Deliverables
BRD
The Business Requirements Document states what the business needs from an instant payment solution, including the rails, currencies, channels and customer segments in scope. It covers initiation from mobile and internet banking, real time validation, timeout handling, duplicate prevention, settlement and confirmation, and it defines the service levels for availability, response time and support. It is signed off by business, operations, compliance and technology before design starts.
Template sections:
- Executive Summary
- Business Objectives and Scope
- Instant Payment Rails and Markets
- Current State and Pain Points
- Target State Capabilities
- Business Rules and SLAs
- Stakeholders and RACI
- Risks, Assumptions and Sign Off
FSD
The Functional Specification Document describes how the instant payment solution must behave from initiation to confirmation, including real time validation of account, limits and funds, sanctions screening in under 10 seconds, routing to the rail, settlement and status reporting. It defines the behaviour for timeouts, duplicates, rejections and returns, and the rules for liquidity checks and queue management. Developers and testers use it as the precise specification for build and test.
Template sections:
- Introduction and Scope
- System Context and Interfaces
- Initiation and Validation Flow
- Real Time Screening and Routing
- Settlement and Confirmation Flow
- Timeout and Duplicate Handling
- Status Reporting and Notifications
- Non Functional Requirements
Process Flow
The Process Flow shows the end to end journey of an instant payment from customer initiation to beneficiary credit and confirmation, with swimlanes for the customer, the channel, the hub, compliance and the clearing system. It shows decision points for validation, screening and liquidity, and the exception paths for timeout, duplicate and rejection. Operations teams use it to understand the new process and to train staff for 24 by 7 support.
Template sections:
- Process Overview and Scope
- Actors and Swimlanes
- Initiation Flow
- Validation and Screening Flow
- Settlement Flow
- Timeout and Duplicate Paths
- Controls and Handoffs
- Timing and Cutoffs
Solution Architecture
The Solution Architecture describes the technology design for instant payments, including the real time processing engine, the message queue, the screening service, the liquidity manager and the clearing interface. It shows how the solution stays available 24 hours a day, how it handles peak volumes, how it fails over between data centres and how it meets security and audit requirements. It guides developers and infrastructure teams during build and deployment.
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 through the instant payment solution, from the channel payload to 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, rail, 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 Clearing Mapping
- Hub to Core Banking Mapping
- Hub to Ledger Mapping
- Validation Rules per Field
- Transformation and Default Rules
- Version History
API Specification
The API Specification defines the interfaces for instant payment initiation, payment status, request for payment and webhook notifications. It lists each endpoint, the request and response payloads, the authentication method, the error codes, the idempotency key handling and the service levels for response time and availability. It lets channel teams, fintech partners and corporates integrate with the instant payment solution safely and consistently.
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 instant payment 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, real time validation, screening, settlement, timeout handling, duplicate prevention and status reporting, with clear priorities and dependencies.
Template sections:
- Epic and Story Structure
- Story: Instant Payment Initiation
- Story: Real Time Validation
- Story: Screening and Routing
- Story: Settlement and Confirmation
- Story: Timeout and Duplicate Handling
- Story: Status Reporting
- Definition of Done
Acceptance Criteria
Acceptance Criteria define the conditions that must be met before an instant payment 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, screening, settlement within 10 seconds, timeout handling and duplicate prevention. Criteria are agreed before development starts and are used as the basis for user acceptance testing and sign off.
Template sections:
- Acceptance Criteria Principles
- Criteria per User Story
- Validation and Screening Criteria
- Settlement Time Criteria
- Timeout and Duplicate Criteria
- Performance Criteria
- Security and Audit Criteria
- Sign Off Checklist
UAT Scenarios
UAT Scenarios describe the business tests that prove the instant payment solution works end to end, from a 250 dollar UPI payment in India to a 2,000 euro SCT Inst payment in Europe and a 5,000 dollar FedNow payment in the United States. Each scenario states the precondition, the test steps, the input, the expected output and the evidence required. Scenarios cover standard payments, timeouts, duplicates, sanction hits, insufficient funds and returns.
Template sections:
- UAT Scope and Approach
- Test Environment and Data
- Scenario: Standard Instant Payment
- Scenario: Timeout and Investigation
- Scenario: Duplicate Prevention
- Scenario: Sanction Hit and Rejection
- Scenario: Return and Recall
- Defect Management and Sign Off
RTM
The Requirements Traceability Matrix links every instant payment 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 solution 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