CNAPS reference guide
How to Verify a CNAPS Code Before You Send Money
A risk-based verification procedure for matching a twelve-digit CNAPS record to the intended bank, branch, beneficiary, currency, and payment channel before release.
Edited by John Lan · Reviewed 2026-07-21
Verification is a chain, not a single search
A safe payment decision combines several independent checks. The weakest workflow copies a number from an email, finds a similar bank name online, and treats the match as confirmation. A stronger workflow asks what each piece of evidence proves. The format checker proves only that the text contains twelve digits. A directory result shows that the same number appears with a bank and branch in the compiled dataset. Neither proves that the person requesting payment controls the named account.
Final confirmation must come from current instructions and a trusted channel associated with the beneficiary or receiving bank. For organizations, the approval process should also establish who may change beneficiary details and who may release funds. The objective is not to eliminate every operational risk with one database. It is to make a mistaken or fraudulent change difficult to pass through all layers unnoticed.
Step 1: collect the complete instruction set
Before searching, put the payment information in one review record: beneficiary legal name, account number, bank name, branch name, city and province, currency, amount, payment purpose, BIC if supplied, CNAPS code if supplied, and any intermediary details. Record where the instruction came from and when it was received. An isolated routing number cannot be assessed against the intended recipient because there is nothing to compare it with.
Prefer account documentation generated by the bank or instructions confirmed during beneficiary onboarding. Treat editable invoices, forwarded messages, screenshots, and chat messages as inputs that require corroboration. If the request changes a bank account or routing value used previously, label it as a change rather than overwriting the old record. That preserves the comparison that often reveals fraud or a simple clerical error.
- Keep Chinese and English branch names when both are available.
- Preserve leading zeroes and avoid spreadsheet cells that convert long codes to numbers.
- Keep the currency and payment channel next to the routing fields.
Step 2: check syntax without overinterpreting it
Paste the CNAPS value into the checker. A valid result means it has exactly twelve numeric digits. An invalid result can expose a missing character, a copied space, punctuation, or a value from another identification system. Correct obvious transcription errors only by returning to the source document. Never append a zero, remove a character, or calculate a substitute merely to make the value pass.
If the value passes, move to comparison. Do not describe it internally as “verified” yet; use language such as “format valid.” Precise status labels matter because a colleague approving the payment may otherwise assume that the bank confirmed it. The same discipline applies to a negative result: “format invalid” does not prove fraud. It means the instruction needs clarification before it can be used.
Step 3: compare bank, location, and branch
Search the full code first, then compare the returned bank and branch with the instruction set. A bank-family match alone is weak evidence because a large institution can have many branches. Compare province, city, and the most specific branch wording available. If transliteration differs, compare original-language names or ask the recipient for clarification instead of choosing the nearest English spelling.
When the full code is missing, use the bank and location finder only to identify possible records for discussion. Do not select a candidate solely because it is the first result or the only result in one translated query. The dataset may be incomplete, outdated, or normalized differently from current bank naming. A missing directory result is a reason to contact the bank, not a reason to route the payment to a head office by default.
- Exact code and exact branch match: useful comparison evidence, but still requires transaction confirmation.
- Exact code and different branch: stop and resolve the discrepancy.
- No record or several plausible branches: obtain the code from the receiving bank.
Step 4: confirm through an independent channel
Use contact information already held in an approved vendor or customer record, the bank's official website, or a known relationship manager. Do not use only a phone number included in the same message that announced new payment details. Read back the complete beneficiary name, account ending, bank branch, currency, and CNAPS code. Ask whether the identifier applies to this specific payment route rather than asking only whether it resembles the bank's code.
For a business process, require a second person to approve new or changed beneficiary instructions. Separate the person who edits master data from the person who releases the payment when practical. Record the confirmation date, channel, person or department contacted, and outcome. Avoid storing unnecessary personal data; the purpose is an audit trail of the decision, not a transcript of every conversation.
Step 5: use a risk-based payment release
The appropriate final control depends on value, urgency, prior history, and organizational policy. A new high-value beneficiary, an unexpected account change, or unusual pressure to pay deserves more review than a recurring low-value payment with unchanged instructions. Ask the sending bank whether a small test payment is available and meaningful for the chosen rail. A successful test can show that funds reached an account, but the beneficiary should still confirm receipt before the remainder is sent.
Do not split payments merely to avoid an internal approval threshold. The test should be documented as a control, not used to bypass review. Check fees and whether the receiving bank can identify the test. After confirmation, release the remaining payment under the normal authorization process and save the exact final instruction version that was used.
Red flags that should pause payment
Pause when bank details change immediately before a due date, the sender discourages a call, the beneficiary name differs from the contract, a personal account replaces a company account without explanation, the location conflicts with known operations, or the code maps to a different branch. Also pause when email domains, reply-to addresses, tone, or invoice layout change unexpectedly. None of these signs alone proves fraud, but urgency should increase verification rather than remove it.
If compromise is suspected, contact the sending bank through its official emergency or fraud channel immediately and follow its recall guidance. Notify the legitimate beneficiary using a trusted contact. Preserve the message and payment records for the bank or authorities. Do not rely on editing the directory entry as an incident response: even a perfect directory cannot reverse a payment or determine who controlled an email account.
A compact approval record
A useful record can fit on one page: payment reference; beneficiary and account; bank, branch, BIC, and CNAPS fields; source document; format-check result; directory-comparison result; discrepancy notes; independent confirmation; approver; and release outcome. Use distinct values such as “format valid,” “directory match,” and “bank or beneficiary confirmed” instead of one ambiguous verified checkbox.
Review saved templates periodically and whenever a bank announces a change. If a correction is reported to CNAPS Code Finder, include the code, current displayed record, proposed correction, and a source that can be checked. The site operator reviews reports but cannot certify transaction instructions. The recipient bank remains the place to resolve an urgent live payment question.
Primary references
These sources support the general definitions and bank-workflow examples in this article. They do not provide row-level provenance for every record in this independent compiled directory.