How the CNAPS Code Directory Is Compiled and Reviewed

Purpose and scope

CNAPS Code Finder is an independently operated reference directory. Its purpose is to help users compare a twelve-digit code with a bank, province, city, and branch record, and to explain how to verify payment instructions safely. It is not operated by the People's Bank of China, Bank of China, Swift, or any bank shown in search results. Inclusion does not indicate a commercial relationship, endorsement, current account capability, or approval for a transfer.

The compiled dataset contains bank and branch records gathered from multiple public reference materials. The site's primary-bank links explain the general meaning and transaction use of CNAPS identifiers; they are not the row-level source for every directory record. That distinction is important. A source that defines CNAPS does not prove that each displayed branch name or address is current, and the site does not present it as such.

Record model

A record can contain a union number, bank family identifier, bank name, branch name, province, city, address, telephone, and Swift code when those fields exist in the collected material. Not every record includes every field. The public detail page emphasizes the CNAPS value and institution/location attributes used for comparison. Blank fields are not filled with guesses, and a missing phone, address, or BIC should not be interpreted as evidence that the branch lacks one.

The directory groups records by the first three digits for navigation. Human-readable province and city slugs are used in URLs, while the stored values support display and lookup. These groups make a large dataset usable, but they are site navigation choices rather than an official taxonomy. A bank may organize its branches differently, and names can change after mergers, relocations, or internal restructuring.

• Core identifier: the complete twelve-digit union number stored as text.
• Comparison fields: bank, branch, province, and city names where available.
• Optional context: address, telephone, or Swift value when present in source material.

Normalization rules

Identifiers are kept as strings so leading zeroes are not lost. Whitespace around imported values is removed, but digits are not invented to repair an invalid length. Location names are normalized for consistent browsing, and URL slugs are separated from display labels. English names may be transliterations or translations found in the collected material; the site does not claim that one English rendering is the bank's current preferred legal name.

Normalization is deliberately conservative. The operator does not merge two records merely because their English names are similar, since large banks can operate many branches with near-identical names. Nor does the operator treat a matching address as proof that two codes are interchangeable. Corrections should preserve the original identifier relationship and use evidence specific enough to distinguish the affected branch.

Automated quality checks

Before publication, application tests require the checker to accept only twelve numeric digits. Sitemap and metadata tests prevent empty, paginated, or non-curated directory routes from being promoted for search indexing. Content tests protect the site's operator disclosure, source links, limitations, and verification guidance. Build and type checks catch broken routes and invalid application code before deployment.

These controls improve consistency; they do not contact a bank or query a live clearing system. A record can pass every syntactic and software check while still being outdated in the real world. The user interface therefore avoids labels such as “verified today,” “official,” or “guaranteed accurate.” The most important quality control remains comparison with current information from the beneficiary bank.

• Format validation catches non-numeric or incorrectly sized identifiers.
• Duplicate grouping prevents repeated bank-family links from overwhelming navigation.
• Index controls keep long-tail or empty combinations available to users without promoting them as standalone editorial pages.

Duplicate and conflict handling

The same bank family can legitimately appear in many places, and similar branch names are not automatically duplicates. Exact repeated records can arise when public materials overlap; those are candidates for deduplication after their fields are compared. When two records share a name but have different union numbers, the directory retains the distinction unless reliable evidence shows that one replaces the other.

Conflicting correction reports are not resolved by counting submissions. The operator asks for specific, checkable evidence and may leave the displayed record unchanged while the conflict remains unresolved. If a user faces a live payment deadline, the correct next step is the bank, not waiting for a directory edit. The correction process is designed to improve future reference quality, not to authorize an individual transfer.

Updates and review dates

Dataset dates are published only when a deployment has a configured update date. The site does not stamp every page with the current day, because that would imply a review that did not occur. Editorial guides carry a separate reviewed date representing a content review, not a live confirmation of all directory rows. Trust and policy pages have their own review dates for the same reason.

There is no claim that every branch is refreshed on a fixed schedule. Bank structures can change faster than a compiled public directory. Users should treat older saved instructions and directory results as prompts for confirmation, particularly after a merger, branch move, account change, or rejected transfer. The absence of a recent dataset date is a limitation to consider, not a signal that the records were silently refreshed.

How to submit a useful correction

Send corrections to [email protected] with the complete twelve-digit code, the page URL, the currently displayed values, the proposed values, and a public or bank-issued source that supports the change. Remove account numbers, identification documents, transaction receipts, and other personal or financial data. The operator may request clarification or decline changes that cannot be distinguished from a similarly named branch.

A good report identifies the exact field and evidence: for example, a bank notice showing that a named branch moved or changed its English name. A weak report says only that a code “does not work,” because rejection can result from many transaction fields outside the directory. The operator reviews reports for future updates but cannot provide individual banking advice or confirm whether a beneficiary account can receive funds.

Known limitations and appropriate use

The directory is compiled, not a real-time bank interface. It may omit records, retain historical entries, contain transliteration differences, or display fields that changed after collection. It cannot check an account, beneficiary, currency capability, sanctions status, transfer purpose, intermediary route, or bank operating status. Primary references linked by the site explain CNAPS concepts and example bank requirements but are not row-level provenance for the compiled directory.

Use the site to understand the identifier, check twelve-digit syntax, narrow a set of candidates, and compare payment instructions. Do not use it as the sole source for a high-value payment or as evidence that a payment request is legitimate. The recommended endpoint for every workflow is the same: confirm the exact routing details with the recipient or receiving bank through a trusted channel, then follow the sending bank's form and approval requirements.