Skip to Content

Payment Pre-Validation


Check payment data before you send it

Cross-border requirements differ by country, market, and regulator. When a payment leaves with the wrong account, identifier, or purpose code, it comes back as a reject or repair, or worse, reaches the wrong party. Pre-validation catches those errors at the start.


Talk to Swift Expert!
What it is.

Validate Before You Pay

Verify payment details before submission using SWIFT Pre-validation APIs. Validate accounts, identifiers, purpose codes and payment data to reduce downstream failures.

Why it matters.

Reduce Payment Failures

Catch incorrect payment details before execution, reducing rejects, repairs, delays and misdirected payments while improving straight-through processing.

How it helps.

Fits Every Payment Flow

Integrates into payment preparation for both MT and ISO 20022 messages, operating securely over the SWIFT network or the internet.

Overview


Pre-validation has two API groups. Central APIs are answered by Swift using reference data and pseudonymised account statistics. Collaborative APIs are routed to another institution acting as a data provider.

API Group
Primary Validation
Outcome

Central

Account format, BIC, purpose code, category purpose, amount, beneficiary account

Aggregates multiple validation checks into a single response.

Collaborative

Beneficiary account existence, ownership, account type, payee name (optional)

Confirms the beneficiary can receive funds before payment execution.

Central Beneficiary Account Verification uses pseudonymised account statistics, not account data. Account numbers are transformed with a one-way function, and Swift stores only aggregated statistics for up to 13 months. Individuals can opt out.

Verification confirms only whether the data you already hold correctly identifies a receivable account. The beneficiary bank does not expose account details, and access is limited to authenticated, registered Swift users. Data providers must respond within defined performance limits, and testing on the Test Sparring Partner is required for providers before go-live.

Benefits


 Fewer rejects and repairs

Confirm account and payment data before submission, so fewer payments come back for correction.


 Lower fraud and misdirection

Beneficiary Account Verification checks that funds go to the intended account, with an optional payee name check.


 Works before execution

Validation runs during payment preparation and does not depend on the payment later moving over Swift.


 Reuse existing infrastructure

Data providers can respond over the internet using TLS and OAuth 2.0, without building on the Swift network.

FAQs

No. Pre-validation is used during payment preparation and works independently of execution. It is also format-agnostic, covering MT and ISO 20022.
No. Verification confirms only whether the data you already hold identifies a receivable account. Swift stores no account data, and access is limited to authenticated registered users.
One of three outcomes: the account may receive funds, may not receive funds, or was not found. It is part of the essential services at no additional cost.
Over the Swift network or over the public internet using TLS and OAuth 2.0. Data providers must meet defined response-time and availability requirements and test before go-live.
No. Any supervised financial institution can act as a consumer, a data provider, or both.

Contact us

Have a question? We're here to help with your SWIFT journey.

Submit