# End-to-End Cross-Border Payment Take a payment from customer instruction to beneficiary credit across borders, with FX and tracking This project delivers end to end cross-border payments, from customer initiation to beneficiary credit, with FX, correspondent banking, sanctions screening and gpi tracking. A 25,000 dollar payment from a London corporate to a New York supplier, a 40,000 euro payment to a Frankfurt beneficiary and a 15,000 pound payment to a Singapore exporter are used as the reference cases, so that serial and cover methods, charge options and value dating are tested on real flows. The business analyst maps the full journey, defines FX and routing rules, specifies screening and clearing integrations, and writes requirements for settlement, beneficiary credit and payment tracking. The project ends with SWIFT certification, user acceptance testing and a controlled production launch. The work also covers nostro funding, liquidity checks and cutoffs, so that payments settle on the agreed value date without delay. ## Phases ### Discovery and Journey Mapping - Map the as is cross-border journey and pain points - Interview corporate customers, operations and compliance - Collect sample payments for USD, EUR and GBP corridors - Identify correspondent banks and clearing routes ### FX and Routing Design - Design FX quotation, rate lock and conversion rules - Define serial versus cover routing logic - Specify charge bearer options and pricing - Design nostro liquidity and funding rules ### Screening and Clearing Design - Define sanctions and fraud screening rules - Design clearing and settlement workflows - Specify gpi tracking and status reporting - Design repair, rejection and investigation flows ### Requirements and API Design - Write the BRD and FSD with business and functional rules - Specify APIs for initiation, FX and gpi tracking - Define cutoffs, value dating and SLAs - Agree non functional requirements for audit and resilience ### Build Support and Testing - Support developers during hub and SWIFT build - Create UAT scenarios for serial, cover and sanction cases - Support SWIFT certification and gpi testing - Track defects and update requirements where needed ### Launch and Hypercare - Plan phased launch by corridor and customer segment - Prepare operations runbooks and training material - Monitor settlement times and gpi tracking in hypercare - Hand over to operations and close the project ## Deliverables ### BRD The Business Requirements Document states what the business needs from end to end cross-border payment processing, from customer initiation and FX through correspondent banking, sanctions screening, clearing and settlement to beneficiary credit and gpi tracking. It covers serial and cover payment methods, charge options, value dating and cutoffs, and it defines the business rules for routing, pricing and exception handling. It is signed off by business, operations, compliance and technology before design starts. Template sections: - Executive Summary - Business Objectives and Scope - Payment Journey and Customer Segments - Current State and Pain Points - Target State Capabilities - Business Rules and Controls - Stakeholders and RACI - Risks, Assumptions and Sign Off ### FSD The Functional Specification Document describes how the cross-border payment system must behave at each stage, from initiation and FX quotation through screening, routing, clearing, settlement and beneficiary credit. It defines the rules for serial versus cover payments, charge bearer options, gpi tracking updates and status reporting through pacs.002. Developers and testers use it as the precise specification for build and test. Template sections: - Introduction and Scope - System Context and Interfaces - Initiation and FX Flow - Screening and Routing Rules - Serial and Cover Processing - Clearing, Settlement and Credit - gpi Tracking and Status Reporting - Non Functional Requirements ### Process Flow The Process Flow shows the end to end journey of a cross-border payment, from a London corporate instructing a 25,000 dollar payment to a New York supplier through FX, screening, correspondent banking and settlement to beneficiary credit. It uses swimlanes for the customer, the bank, the correspondent and the clearing system, and it shows the exception paths for repair, rejection and investigation. Operations teams use it to understand the process and train staff. Template sections: - Process Overview and Scope - Actors and Swimlanes - Initiation and FX Flow - Screening and Routing Flow - Clearing and Settlement Flow - Exception and Investigation Paths - Controls and Handoffs - Timing and Cutoffs ### Solution Architecture The Solution Architecture describes the technology design for cross-border payments, including the channel layer, the payment hub, the FX engine, the screening platform, the SWIFT interface and the nostro account manager. It shows how payments flow through correspondent banks, how liquidity is managed, how gpi tracking is updated and how the design meets security, performance and audit requirements. 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 through the cross-border payment, from the customer instruction to the pacs.008 message, the nostro entry and the ledger. It shows the source, the target, the data type, the transformation rule and the validation rule for each field, including party, agent, amount, currency, FX rate, charges and value date. It is the reference that developers and testers use to build and verify every interface. Template sections: - Mapping Overview and Conventions - Customer to Hub Field Mapping - Hub to pacs.008 Mapping - Hub to Nostro Mapping - Hub to Ledger Mapping - Validation Rules per Field - Transformation and Default Rules - Version History ### API Specification The API Specification defines the interfaces for cross-border payment initiation, FX quotation, payment status, gpi tracking and webhook notifications. It lists each endpoint, the request and response payloads, the authentication method, the error codes and the service levels for response time and availability. It lets channel teams, corporates and fintech partners integrate with cross-border payments safely. It also covers bulk initiation, rate lock expiry and secure access for corporates, channels and fintech partners. Template sections: - API Overview and Principles - Authentication and Authorisation - Endpoint Catalogue - Request and Response Payloads - Error Codes and Handling - FX Quotation and Rate Lock - Performance and Rate Limits - Versioning and Change Control ### Jira User Stories Jira User Stories break the cross-border 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, FX, screening, routing, clearing, settlement, beneficiary credit and gpi tracking, with clear priorities and dependencies. Template sections: - Epic and Story Structure - Story: Payment Initiation and FX - Story: Screening and Routing - Story: Serial and Cover Processing - Story: Clearing and Settlement - Story: Beneficiary Credit - Story: gpi Tracking and Reporting - Definition of Done ### Acceptance Criteria Acceptance Criteria define the conditions that must be met before a cross-border 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 FX, screening, routing, settlement, beneficiary credit and gpi tracking. 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 - FX and Screening Criteria - Routing and Settlement Criteria - Beneficiary Credit Criteria - Performance Criteria - Security and Audit Criteria - Sign Off Checklist ### UAT Scenarios UAT Scenarios describe the business tests that prove cross-border payments work end to end, from a 25,000 dollar payment to New York to a 40,000 euro payment to Frankfurt and a 15,000 pound payment to Singapore. Each scenario states the precondition, the test steps, the input, the expected output and the evidence required. Scenarios cover serial and cover payments, FX, sanction hits, repair, rejection, beneficiary credit and gpi tracking. Template sections: - UAT Scope and Approach - Test Environment and Data - Scenario: Serial Payment - Scenario: Cover Payment - Scenario: FX and Charges - Scenario: Sanction Hit and Repair - Scenario: Beneficiary Credit and gpi - Defect Management and Sign Off ### RTM The Requirements Traceability Matrix links every cross-border 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