Payments Training Hub

Capstone Projects › End-to-End Cross-Border Payment

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

FX and Routing Design

Screening and Clearing Design

Requirements and API Design

Build Support and Testing

Launch and Hypercare

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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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