Capstone Projects | PaymentForge

Project-Based Learning Track

6 end-to-end projects. Each one produces the deliverables a payments BA or architect produces on a real project: BRD, FSD, process flow, solution architecture, data mapping sheet, API specification, Jira user stories, acceptance criteria, UAT scenarios and RTM. Download the project brief to work from it offline.

MT103 to ISO 20022 Migration

Move cross-border payments from legacy MT messages to ISO 20022 before the coexistence deadline

This project migrates cross-border payment instructions from SWIFT MT103, MT202 and MT202 COV messages to ISO 20022 pacs.008 and pacs.009 messages, following the end of MT coexistence on 22 November 2025. The work covers a 10,000 dollar payment from a London corporate to a New York supplier, a 50,000 euro payment to a Frankfurt beneficiary and a 25,000 pound payment to a Singapore exporter, so that transformation, truncation and screening are tested on real cases. The business analyst maps every MT field to its ISO 20022 target, defines rules for structured party and address data, handles fields that truncate or have no direct equivalent, and writes requirements that developers, testers and operations teams can use. The project ends with SWIFT certification, user acceptance testing and a controlled production cutover.

Read the brief · Download project brief (p1.md)

Phases

Discovery and Current State Analysis
- Document the as is MT103, MT202 and MT202 COV flows and volumes
- Interview operations, compliance and technology stakeholders
- Collect sample MT messages for USD, EUR and GBP payments
- Identify downstream systems that consume MT data
ISO 20022 Analysis
- Analyse pacs.008, pacs.009 and pacs.002 structure and CBPR+ rules
- Compare MT and MX fields and identify gaps and truncations
- Document structured address and party data requirements
- Review SWIFT MyStandards usage guidelines for each market
Mapping and Transformation Design
- Create the MT to MX field mapping sheet for all message types
- Define truncation, enrichment and default value rules
- Agree handling for fields with no direct MX equivalent
- Validate mapping with compliance and screening teams
Requirements and Design
- Write the BRD and FSD with business and functional rules
- Define API contracts for initiation and status reporting
- Design repair, rejection and reversal workflows
- Agree non functional requirements for performance and audit
Build Support and Testing
- Support developers during transformation engine build
- Create UAT scenarios for standard, truncated and sanction hit cases
- Support SWIFT certification and community testing
- Track defects and update requirements where needed
Cutover and Go Live
- Plan the phased cutover from MT to MX traffic
- Prepare operations runbooks and training material
- Support hypercare and monitor message success rates
- Close the project and hand over to operations

Deliverables

BRD. The Business Requirements Document states what the business needs from the MT103 to ISO 20022 migration, why the change is required, and what success looks like. It covers the scope of MT103, MT202 and MT202 COV migration, the affected payment products, the business rules for structured data, truncation and enrichment, and the non functional requirements for performance, audit and reporting. It is signed off by business, operations, compliance and technology before design starts.

FSD. The Functional Specification Document describes how the payment hub, transformation engine and screening systems must behave to convert MT103 messages to pacs.008 messages. It defines field level mapping rules, validation rules, error handling, status reporting through pacs.002, and the behaviour for repair, rejection and reversal. It gives developers and testers a precise, testable specification for every message type, interface and business rule in scope.

Process Flow. The Process Flow shows the end to end journey of a cross-border payment from MT103 receipt to pacs.008 delivery, including validation, enrichment, screening, transformation and settlement. It uses swimlanes for customer, operations, compliance and technology, shows decision points for repair and rejection, and identifies the systems and people responsible at each step. It is the reference that operations and business teams use to understand the new process.

Solution Architecture. The Solution Architecture describes the target technology design for the migration, including the payment hub, the message transformation engine, the SWIFT interface, the screening platform and the core banking system. It shows how messages flow between systems, where data is stored, how resilience and failover work, and how the design meets security, performance and audit requirements. It guides developers and infrastructure teams during build and deployment.

Data Mapping Sheet. The Data Mapping Sheet lists every MT103 field and its target in pacs.008, with the transformation rule, the data type, the length, the mandatory or optional status, and the handling for truncation, enrichment and default values. It covers party data, agent data, remittance information and charges, and it flags fields that have no direct equivalent and need a business decision. Developers build from this sheet and testers verify against it.

API Specification. The API Specification defines the interfaces that expose payment initiation, payment status and message transformation services to channels, the core banking system and partner systems. It lists each endpoint, the request and response payloads in ISO 20022 XML or JSON, the authentication method, the error codes and the service level for response time and availability. It lets channel and integration teams build against a stable contract.

Jira User Stories. Jira User Stories break the migration into small, deliverable pieces of work that a development team can build and test 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 message ingestion, transformation, screening, status reporting, repair screens and regression testing, with clear priorities and dependencies.

Acceptance Criteria. Acceptance Criteria define the conditions that must be met before a user story, a release or the full migration is accepted by the business. Each criterion is specific, measurable and testable, and it states the expected result for a given input, including message validation, transformation accuracy, screening behaviour and status reporting. Criteria are agreed before development starts and are used as the basis for user acceptance testing and sign off.

UAT Scenarios. UAT Scenarios describe the business tests that prove the migration works end to end, from a customer instruction to beneficiary credit and status reporting. Each scenario states the precondition, the test steps, the input message, the expected output and the evidence required. Scenarios cover a 10,000 dollar MT103 to a US beneficiary, a 50,000 euro payment with structured remittance data, a payment with a truncated name, a sanction hit and a timeout, so the business can sign off with confidence.

RTM. The Requirements Traceability Matrix links every business 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 build. It is the main evidence that the migration meets the agreed scope and is ready for production release.

Test scenarios

Input a 10,000 dollar MT103 from a London corporate to a New York supplier. Submit the message through the transformation engine and check the output. Expected result is a valid pacs.008 with the correct creditor, amount, charges, and remittance information, and no validation errors.
Input a 50,000 euro MT103 with structured remittance data for a Frankfurt beneficiary. Submit the message and inspect the pacs.008 output. Expected result is structured remittance information preserved in full, with the creditor name and address mapped to the correct structured elements.
Input a 25,000 pound MT103 where the beneficiary name exceeds the target length. Submit the message and review the handling. Expected result is the payment routed to repair with a clear truncation warning, and no data lost silently in the pacs.008 output.
Input an MT103 where the beneficiary appears on a sanctions list. Submit the message and monitor the screening outcome. Expected result is the payment held for compliance review, a pacs.002 status report sent, and no pacs.008 released to the beneficiary bank.
Input an MT103 with an invalid IBAN for the beneficiary account. Submit the message and check the validation response. Expected result is the payment rejected to repair with a clear error code, and the original MT103 retained for audit with no partial transformation.

Evaluation criteria

Transformation accuracy: at least 99.5 percent of test messages transform with zero field errors, measured across 1,000 test messages in every test run.
Structured data handling: 100 percent of structured party and address fields map to the correct pacs.008 elements in the test pack.
Screening control: 100 percent of sanction hit test cases are held before release, with a pacs.002 status report sent in each case.
Repair handling: at least 95 percent of truncation and validation cases route to repair with a clear error code and no silent data loss.
Certification readiness: the full UAT pack passes with no open severity one defects and SWIFT certification evidence complete before the launch decision.

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.

Read the brief · Download project brief (p2.md)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Test scenarios

Input a 5,000 dollar domestic payment through internet banking. Submit the payment through the hub and track its journey. Expected result is validation, screening, and routing completed, settlement confirmed, and a real time status update shown to the customer.
Input a 100,000 euro cross-border payment to a Frankfurt beneficiary. Submit the payment and check the routing decision. Expected result is the payment routed to the correct SWIFT rail, charges applied as agreed, and settlement completed on the stated value date.
Input the same 20,000 dollar payment twice within two seconds using the same reference. Submit both requests and inspect the hub response. Expected result is one payment created, the duplicate blocked, and the customer shown a single confirmation with one payment identifier.
Input a payment where the beneficiary appears on a sanctions list. Submit the payment and monitor the screening outcome. Expected result is the payment held for compliance review, the customer told that checks are in progress, and no funds released.
Input a bulk file of 200 salary payments totalling 150,000 pounds. Upload the file and review the processing result. Expected result is every valid payment accepted, any invalid record listed with a clear error, and a summary report showing the accepted and rejected counts.

Evaluation criteria

Routing accuracy: at least 99 percent of test payments route to the correct rail, measured across domestic, cross-border, and instant cases.
Duplicate prevention: 100 percent of duplicate submissions in the test pack are blocked, with only one payment created in each case.
Screening control: 100 percent of sanction hit test cases are held before settlement, with an audit record created for each hold.
Status reporting: at least 98 percent of test payments show a correct real time status at each stage, from initiation to settlement.
UAT readiness: the full UAT pack passes with no open severity one or two defects and business sign off recorded for each release.

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.

Read the brief · Download project brief (p3.md)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Test scenarios

Input a 250 dollar instant payment through the mobile app in India. Submit the payment and measure the end to end time. Expected result is beneficiary credit and sender confirmation within 10 seconds, with the payment reference shown on the confirmation screen.
Input a 2,000 euro SCT Inst payment to a beneficiary in Europe. Submit the payment and check the settlement record. Expected result is settlement completed within 10 seconds, the beneficiary credited, and the sender notified with the correct amount and value date.
Input a 5,000 dollar FedNow payment where the clearing system does not respond. Submit the payment and wait for the timeout. Expected result is the payment marked as unknown after 15 seconds, the customer told that the bank is checking, and the funds released if settlement did not occur.
Input the same 750 pound instant payment twice by tapping send twice. Submit both requests with the same idempotency key and inspect the result. Expected result is one payment created, the second request returning the original confirmation, and no duplicate beneficiary credit.
Input a 1,500 dollar instant payment from an account with insufficient funds. Submit the payment and check the response. Expected result is immediate rejection with a clear insufficient funds message, no settlement attempted, and the account balance unchanged.

Evaluation criteria

Settlement speed: at least 95 percent of test payments complete within 10 seconds, measured from initiation to beneficiary credit in the test pack.
Duplicate prevention: 100 percent of duplicate submissions in the test pack create only one payment, with the original confirmation returned.
Timeout handling: 100 percent of timeout test cases are marked as unknown, investigated, and resolved with the customer informed in the test pack.
Availability: the solution meets 99.9 percent availability in the test window, with no unplanned outage longer than five minutes during testing.
Scheme readiness: certification passes for each rail in scope, with no open severity one defects at the launch decision point.

Payment Reconciliation

Match every clearing record to the ledger, find breaks fast and resolve them cleanly

This project builds payment reconciliation that matches every clearing record to the ledger, identifies breaks quickly and resolves them before they affect customers or financial reporting. A 10,000 dollar SWIFT payment, a 500 euro SEPA credit transfer and a 2,000 pound Faster Payments transfer must each match to the correct ledger entry, with fees, FX and value dates handled correctly. The business analyst defines the matching rules, the tolerance for charges and FX differences, the exception workflows for missing, duplicate and partial matches, and the reports that finance and operations use to track breaks. The project covers file receipt, auto matching, case management, suspense accounting and daily, weekly and monthly reconciliation reporting. It also covers suspense accounting, write off approval and audit trails that prove each break was investigated and resolved on time.

Read the brief · Download project brief (p4.md)

Phases

Discovery and Current State Analysis
- Document current reconciliation processes and break volumes
- Interview finance, operations and audit stakeholders
- Collect sample clearing files and ledger extracts
- Identify high risk accounts and payment types
Matching Rules Design
- Define matching keys for amount, currency and reference
- Set tolerances for fees, FX and value date differences
- Design rules for partial, duplicate and missing matches
- Agree suspense and write off rules with finance
Requirements and Workflow Design
- Write the BRD and FSD with business and functional rules
- Design break workflow, ageing and escalation rules
- Define reconciliation reports and dashboards
- Agree controls, audit trails and sign off rules
Build Support
- Support developers during matching engine build
- Create test data for match, break and write off cases
- Support API and file interface testing
- Track defects and update requirements where needed
Testing and Validation
- Create UAT scenarios for each break type
- Run parallel reconciliation with the old process
- Validate reports against finance expectations
- Obtain business sign off for each release
Go Live and Stabilisation
- Plan cutover to daily automated reconciliation
- Prepare finance and operations runbooks and training
- Monitor match rates and break ageing in hypercare
- Hand over to finance and close the project

Deliverables

BRD. The Business Requirements Document states what the business needs from payment reconciliation, including the payment types, accounts, ledgers and clearing systems in scope. It covers receipt of clearing files and ledger records, matching rules, break identification, exception workflows and reporting. It defines the business rules for tolerance, value dating, charges and suspense accounting, and it is signed off by finance, operations and technology before design starts.

FSD. The Functional Specification Document describes how the reconciliation system must behave, from file ingestion and data validation through matching, break creation, exception workflow and reporting. It defines the matching rules for amount, currency, value date and reference, the tolerance for fees and FX, and the behaviour for partial matches, duplicates and missing records. Developers and testers use it as the precise specification for build and test.

Process Flow. The Process Flow shows the end to end reconciliation journey, from receipt of the clearing file to matched records, breaks, investigation and resolution. It uses swimlanes for finance, operations and technology, shows decision points for auto match, manual match and write off, and identifies the systems and people responsible at each step. Finance teams use it to understand the new process and to train staff.

Solution Architecture. The Solution Architecture describes the technology design for reconciliation, including file ingestion, the matching engine, the case management system, the data warehouse and the reporting layer. It shows how the system connects to clearing systems, the core banking ledger, the payment hub and the general ledger, and how it handles large volumes, data retention and audit. It guides developers and infrastructure teams during build.

Data Mapping Sheet. The Data Mapping Sheet lists every field that flows into reconciliation, from the clearing file, the ledger and the payment hub. It shows the source, the target, the data type, the transformation rule and the validation rule for each field, including transaction reference, amount, currency, value date, charges and status. It is the reference that developers and testers use to build and verify every interface and matching rule.

API Specification. The API Specification defines the interfaces for reconciliation file upload, break retrieval, case updates and reporting. 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 operations, finance and audit teams access reconciliation data and update cases through a stable, secure contract. It also covers bulk upload, status polling and secure access for finance, operations and audit teams.

Jira User Stories. Jira User Stories break the reconciliation 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 file ingestion, matching, break workflow, reporting and dashboards, with clear priorities, dependencies and a definition of done.

Acceptance Criteria. Acceptance Criteria define the conditions that must be met before a reconciliation feature or release is accepted by the business. Each criterion is specific, measurable and testable, and it states the expected result for a given file or break, including matching accuracy, break creation, workflow routing and reporting. Criteria are agreed before development starts and are used as the basis for user acceptance testing and sign off.

UAT Scenarios. UAT Scenarios describe the business tests that prove reconciliation works end to end, from a 10,000 dollar SWIFT payment matched to the ledger to a 500 euro SEPA payment with a fee difference and a missing clearing record. Each scenario states the precondition, the test steps, the input, the expected output and the evidence required. Scenarios cover auto match, partial match, duplicate, missing record and write off cases.

RTM. The Requirements Traceability Matrix links every reconciliation 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 system meets the agreed scope and is ready for production release.

Test scenarios

Input a clearing file and a ledger extract containing a 10,000 dollar SWIFT payment. Run the matching engine and review the result. Expected result is an automatic match on reference, amount, and currency, with the match recorded and no break created.
Input a 500 euro SEPA payment where the ledger shows 498.50 euros after a 1.50 euro fee. Run the matching engine and check the outcome. Expected result is a match within the agreed 2 euro tolerance, with the fee recorded separately and no break created.
Input a ledger entry for a 2,000 pound Faster Payments transfer with no clearing record. Run the matching engine and review the break. Expected result is a break created with the missing record reason, an owner assigned, and the item aged from the value date.
Input a clearing file containing the same 3,000 dollar payment twice. Run the matching engine and inspect the handling. Expected result is one record matched, the duplicate flagged, and only one ledger entry affected by the payment.
Input a 7,500 dollar payment where the clearing amount differs from the ledger by 25 dollars. Run the matching engine and check the outcome. Expected result is a break created outside tolerance, routed to investigation, and no automatic write off applied.

Evaluation criteria

Auto match rate: at least 98 percent of test records match automatically, measured across SWIFT, SEPA, and Faster Payments cases.
Tolerance handling: 100 percent of fee differences within tolerance match correctly in the test pack, with the fee recorded separately in each case.
Break creation: 100 percent of missing, duplicate, and out of tolerance test cases create a break with an owner and an age.
Ageing control: no test break remains unassigned after one business day, and every break carries a clear next action in the test pack.
Reporting accuracy: the daily reconciliation report balances in every test run, with match rate, break count, and suspense balance correct.

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.

Read the brief · Download project brief (p5.md)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Test scenarios

Input a 25,000 dollar payment from a London corporate to a New York supplier using the cover method. Submit the instruction and track settlement. Expected result is the pacs.008 sent directly to the beneficiary bank, funds settled through the correspondent, and credit confirmed with a pacs.002 report.
Input a 40,000 euro payment to a Frankfurt beneficiary using the serial method. Submit the instruction and check each intermediary step. Expected result is the instruction passing through each correspondent, charges deducted as agreed, and the beneficiary credited with the correct net amount.
Input a 15,000 pound payment to a Singapore exporter submitted after the 11:00 cutoff. Submit the instruction and review the value date. Expected result is the payment queued for the next business day, the customer told immediately, and no same day value promised.
Input a cross-border payment where the foreign exchange rate is locked at 1.27 dollars to the pound. Submit the payment and verify the debit. Expected result is the sterling account debited at the locked rate, the dollar amount unchanged, and the rate shown on the customer confirmation.
Input a cross-border payment where the beneficiary bank returns the payment as undeliverable. Process the return and check the handling. Expected result is the funds credited back to the sender, charges explained, the customer notified, and the full trail recorded for audit.

Evaluation criteria

Settlement accuracy: at least 99 percent of test payments settle on the agreed value date, measured across all three reference cases.
Charge transparency: 100 percent of test payments apply the agreed charge bearer option, with the net beneficiary amount correct in each case.
Tracking completeness: 100 percent of test payments show a correct status at initiation, settlement, and beneficiary credit in the test pack.
Cutoff handling: 100 percent of late submissions in the test pack are queued correctly, with the customer told immediately in every case.
Launch readiness: the full UAT pack passes with no open severity one defects and SWIFT certification evidence complete before the launch decision.

Payment API Integration

Let corporate treasury systems initiate payments directly, safely and in real time

This project builds a payment initiation API for the corporate banking channel, so that treasury teams can send payments from their own systems instead of typing each instruction into internet banking. A corporate customer submits a payment of 25,000 dollars to a supplier in New York, a payment of 100,000 euros to a supplier in Frankfurt, and a bulk file of 200 salary payments, all through the same API, and receives a real time response with the payment status. The business analyst defines the business problem, writes the requirements for initiation, validation, approval, screening and status reporting, designs the idempotency and error handling rules, and specifies the API contract that corporate customers build against. The project covers OAuth 2.0 authentication, daily limits, approval workflows, webhook notifications, sandbox testing and a controlled production launch with the first corporate customers.

Read the brief · Download project brief (p6.md)

Phases

Discovery and Business Case
- Document current corporate payment processes and pain points
- Interview corporate customers, channel and operations teams
- Define API objectives, target customers and measurable benefits
- Agree scope, payment types, currencies and launch customers
Requirements and API Design
- Write business requirements for initiation, status and cancellation
- Design endpoints, schemas, error codes and idempotency rules
- Define limits, approval workflows and cutoff rules
- Agree non functional requirements for security and performance
Architecture and Integration Design
- Define API gateway, orchestration and hub components
- Design integrations with screening, core banking and clearing
- Specify authentication, authorisation and rate limiting
- Agree data model, logging, audit and resilience design
Build Support
- Support developers during API and orchestration build
- Create sandbox test data for corporate integration teams
- Support API testing with the first corporate customers
- Track defects and update requirements where needed
Testing and Certification
- Create UAT scenarios for standard, duplicate and timeout cases
- Support performance, security and penetration testing
- Run certification with clearing systems and corporate partners
- Obtain business sign off for each release
Launch and Hypercare
- Plan phased launch by corporate customer and payment type
- Prepare integration guides, runbooks and support training
- Monitor API success rates and response times in hypercare
- Hand over to operations and close the project

Deliverables

BRD. The Business Requirements Document states what the business needs from a payment initiation API for the corporate banking channel, including the payment types, currencies, channels and customer segments in scope. It covers single and bulk payment initiation, payment status enquiry, cancellation and webhook notifications, and it defines the business rules for limits, cutoffs, approval workflows, charges and exception handling. It is signed off by business, operations, compliance and technology before design starts.

FSD. The Functional Specification Document describes how the payment initiation API must behave at each step, from request receipt and authentication through validation, limit checks, screening, routing and status reporting. It defines the rules for idempotency, duplicate prevention, timeout handling, retries and error reporting, and it states the behaviour for approvals, rejections and cancellations. Developers and testers use it as the precise specification for build and test.

Process Flow. The Process Flow shows the end to end journey of a payment initiated through the API, from the corporate treasury system to beneficiary credit, with swimlanes for the customer, the API gateway, the payment hub, compliance and the clearing system. It shows decision points for authentication, validation, approval, screening and routing, and the exception paths for rejection, timeout and duplicate detection. Operations and integration teams use it to understand the new process and to train staff.

Solution Architecture. The Solution Architecture describes the technology design for the payment API, including the API gateway, the authentication service, the payment orchestration service, the payment hub, the screening platform and the core banking system. It shows how requests flow between systems, where idempotency keys and correlation IDs are stored, how resilience and failover work, and how the design meets security, performance and audit requirements. It guides developers and infrastructure teams during build and deployment.

Data Mapping Sheet. The Data Mapping Sheet lists every field that flows through the API, from the corporate request payload to the payment hub 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, remittance information and charges. It is the reference that developers and testers use to build and verify every interface.

API Specification. The API Specification defines the interfaces for payment initiation, payment status, payment cancellation, bulk file submission 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, the correlation ID rules and the service levels for response time and availability. It lets corporate customers and channel teams integrate with the bank safely and consistently.

Jira User Stories. Jira User Stories break the API 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 authentication, initiation, validation, approval, screening, status reporting, cancellation and webhooks, with clear priorities, dependencies and a definition of done.

Acceptance Criteria. Acceptance Criteria define the conditions that must be met before an API feature or release is accepted by the business. Each criterion is specific, measurable and testable, and it states the expected result for a given request, including authentication, validation, approval, idempotency, status reporting and error handling. Criteria are agreed before development starts and are used as the basis for user acceptance testing, performance testing and production sign off.

UAT Scenarios. UAT Scenarios describe the business tests that prove the API works end to end, from a 25,000 dollar payment initiated by a corporate treasury system to a 100,000 euro bulk file and a cancelled payment. Each scenario states the precondition, the test steps, the input request, the expected output and the evidence required. Scenarios cover a standard single payment, a payment above the approval threshold, a duplicate submission, an invalid IBAN, a timeout, a cancellation and a webhook delivery, so the business can sign off with confidence.

RTM. The Requirements Traceability Matrix links every API 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 API meets the agreed scope and is ready for production release.

Test scenarios

Input a 25,000 dollar payment request from a corporate treasury system with a valid OAuth 2.0 token. Submit the POST request and check the response. Expected result is a 202 response with a payment identifier, a status of accepted, and a correlation ID returned for tracking.
Input a 100,000 euro payment above the approval threshold of 50,000 euros. Submit the request and review the workflow. Expected result is the payment held for approval, the approver notified, and no settlement attempted until approval is recorded.
Input the same payment request twice with the same idempotency key. Submit both requests and inspect the result. Expected result is one payment created, the second request returning the original response, and no duplicate payment sent to the beneficiary.
Input a payment request with an invalid IBAN for the beneficiary account. Submit the request and check the error response. Expected result is a 422 response with a clear business error code, no payment created, and the error message explaining the validation failure.
Input a bulk file of 200 salary payments through the API. Submit the file and review the processing summary. Expected result is every valid payment accepted, each invalid record listed with its error, and a summary showing the accepted and rejected counts.

Evaluation criteria

Idempotency control: 100 percent of duplicate requests in the test pack return the original response, with only one payment created.
Approval control: 100 percent of payments above the threshold are held for approval, with no settlement before approval is recorded.
Error clarity: 100 percent of validation failures return the correct HTTP status and a clear business error code in the test pack.
Response time: at least 95 percent of API requests respond within two seconds in the performance test, excluding bulk file submission.
Launch readiness: the full UAT pack passes with no open severity one defects and sandbox testing signed off by the first corporate customers.