Payment Pre-validation: checking the beneficiary before sending

Payment Pre-validation is the SWIFT service that lets a sending bank check the beneficiary account details before the payment is sent, so that errors are caught while they are still cheap to fix. The bank sends the beneficiary account number and name to the beneficiary bank, or to a validation service, and receives an answer saying whether the account exists, whether the name matches, and whether the account can receive the payment. It is a pre-flight check, and its value is that a payment that would have failed after it was sent, and cost a return and a resend, now fails before it is sent, and costs nothing. Source: SWIFT Payment Pre-validation service description, and SWIFT CBPR+ usage guidelines. Why pre-validation exists is that most cross-border payment failures are data failures, not money failures. The IBAN is wrong by one digit, the account is closed, the name does not match the account holder, or the account cannot receive the currency, and each of those is discovered only when the payment is rejected at the beneficiary bank, days after it was sent. The return then takes days more, the customer is told the payment failed, and the bank pays the cost of the investigation. Pre-validation moves the discovery to before the payment, when the customer is still at the screen and can correct the details in seconds, and the bank never sends a payment it knows will fail. The parties are the sending bank, which requests the validation, the beneficiary bank, which answers it, and the customer, who provides the details and corrects them when the validation fails. The validation service in the middle, operated by SWIFT, routes the request to the right beneficiary bank and returns the answer, and it must do so quickly, because a validation that takes an hour is useless for a customer waiting at a screen. The beneficiary bank must answer accurately, because a validation that says an account exists when it does not is worse than no validation at all, and the liability for a wrong answer is a commercial question the banks must agree in advance. How it works is shown by a worked example. A corporate customer in London must pay a new supplier in Tokyo JPY 4,200,000, and enters the supplier account number and name. The London bank sends a pre-validation request, and the Tokyo bank replies within seconds that the account exists but the name does not match: the account holder is Tokyo Trading Co Ltd, not Tokyo Trading Company Ltd. The customer corrects the name, the validation passes, and the payment is sent and credited the same day. Without pre-validation the payment would have been sent with the wrong name, held for investigation at the Tokyo bank, and returned after three days, and the supplier would have waited a week for money that should have arrived in a day. On success the payment is sent once, credited once, and the customer never learns that a failure was prevented, which is the quiet value of the service. On failure the validation itself can fail, for example because the beneficiary bank does not participate, and then the sending bank must decide whether to send the payment anyway, with a warning to the customer, or to block it until the details can be checked another way. The recovery is a clear message to the customer: the account could not be validated, here is why, and here is what to do, because a customer who is told only that the payment cannot be sent will call the bank, and the call costs more than the validation. The data in a pre-validation request is the beneficiary account identification, usually the IBAN or local account number, the beneficiary name, the currency, and the sending bank identification. The answer is a match result, which can be a full match, a partial match, a no match, or a cannot-validate response, and each one needs a different customer message. A BA must specify the match rules, the customer message for each result, the timeout, and what happens when the beneficiary bank does not answer, because a validation request that hangs for an hour is a customer waiting for an hour, and the business must choose the timeout, not the developer. Edge cases show the depth. A name match is not a simple string comparison, because a name can be written in different scripts, with different abbreviations, or with a legal suffix that the customer omitted, so the matching must tolerate defined variations and must say which variations it tolerates. A validation for an account that exists but is closed must return a clear answer, not a match, because the payment would fail. A validation for a payment in a currency the account cannot hold must say so, because the payment would be rejected or converted at a poor rate. Each of these is a case the BA must specify, because the developer cannot guess them. The effect on the bank is fewer returns, fewer investigations and fewer customer complaints, and the saving is measurable in the return rate, which should fall sharply after pre-validation is introduced. The effect on the customer is a payment that arrives first time, and a correction made in seconds at the screen, instead of a return discovered days later. The effect on operations is a new service to monitor, with a validation success rate, a match rate and a response time, and a manager who can see whether the service is working or whether customers are being blocked by false mismatches. What a BA, PO or SME must understand is that pre-validation is a control that prevents failures, and its value is measured in failures that do not happen, which is harder to prove than failures that are fixed. The requirement must name the validation trigger, the match rules, the customer messages, the timeout and the fallback when validation is unavailable. The test is to take one payment with a wrong beneficiary name, run it through pre-validation, and check that the customer is asked to correct it before the payment is sent, because if the payment is sent anyway, the service is decoration. Further reading: SWIFT Payment Pre-validation service description; SWIFT CBPR+ usage guidelines; Bank for International Settlements, payment system glossaries. Last reviewed 7 November 2026.