BIC Validation ≠ SEPA Participation: Three Separate Layers

"I typed the BIC into the tool, it came back valid — so I can make a SEPA transfer to this bank" is one of the most common but riskiest shortcuts in the payments world. Validating a BIC can actually cover three entirely different questions, and only the first of them is answered by a lookup tool. These three questions are: (1) Is this code formally correct? (2) Does this institution participate in the relevant SEPA scheme? (3) Is this institution actually reachable for the payment I will send? This guide separates the three layers and shows which source answers each.

The three layers in one table

Layer 1 — Structural validity: what a BIC lookup does and does not do

The BIC (Business Identifier Code, in everyday language the SWIFT code) is defined by the ISO 9362 standard and consists of 8 or 11 characters. The first 4 characters are the institution code, the next 2 are the country code (ISO 3166), the next 2 are the location code, and, if present, the last 3 are the branch code. A BIC lookup tool checks the length of these components, the character type (letter/digit) and whether the country code corresponds to a known country. So the question it answers is narrow and clear: "Does this string look like a valid BIC?"

This tool cannot do the following: it cannot verify that the institution is still in operation today (BICs can be retired or change through a merger), it cannot say that the institution participates in any SEPA scheme, and it cannot guarantee that a specific payment you will send will arrive. Format validity is only the first rung of the verification ladder — necessary but not sufficient on its own.

Layer 2 — Scheme participation: only the EPC Register verifies it

Whether an institution participates in a SEPA scheme cannot be read from the format; the only authoritative source for this is the European Payments Council's (EPC) Register of Participants. This official list contains the payment service providers that actually participate in each scheme, and the critical point is this: each scheme is assessed separately. An institution:

• may be in the SCT (SEPA Credit Transfer — standard euro transfer) scheme,
• but may not be in the SCT Inst (instant transfer) scheme,
• participation in SDD Core (consumer direct debit) and SDD B2B (corporate) is separate,
• and participation in VoP (Verification of Payee) is again a separate record.

Therefore the question "is the bank in SEPA?" is incomplete on its own; the correct question should be "which scheme does the bank participate in?". A BIC appearing under SCT in the EPC list does not mean that the same institution is also reachable under SCT Inst or SDD. For each payment type, the relevant scheme must be verified separately.

Scheme participation ≠ customer availability ≠ operational status

Even if scheme participation is verified, this alone does not mean the service is offered to you. Never confuse the three concepts:

• Scheme participation: The institution appearing under the relevant scheme in the EPC Register of Participants.
• Customer availability: This feature being enabled in your individual or corporate account plan/product. A bank may be registered for a scheme and offer the feature only on certain plans.
• Operational status: Whether the institution is actually providing the service at that moment (maintenance, restrictions, channel differences, etc.).

This threefold distinction is the essence of the difference between "a mathematically valid code" and "a working payment route". The EPC list verifies the second layer (scheme participation); for customer availability and operational status you need to take your bank's current product/tariff page, and when necessary the bank directly, as the source of confirmation.

Layer 3 — Reachability: the CNOR / DNOR reject codes

The third and often overlooked layer is reachability: even if the institution is registered for the relevant scheme, it may not actually be reachable for the specific payment you will send at that moment. Reachability problems differ from a format error and usually show up with a reason code when the transaction is returned. Two typical examples:

• CNOR — The creditor's (recipient's) bank / the creditor is not reachable in the relevant scheme.
• DNOR — The debtor's bank / the debtor is not reachable in the relevant scheme (especially in SDD direct debit).

These codes do not report a format error; the code may well be valid and the institution may well exist. What they report is that the target is not reachable for this payment in this scheme. When a transfer is returned with such a code, the solution is not to "fix" the BIC but to choose the right scheme/channel or to verify whether the recipient is reachable in that scheme. If you want to see the exact meaning of the returned code, you can make use of our reason-code tools.

The practical verification order

If you want to assess a BIC safely before a euro payment, apply the three steps in order; no step replaces the previous one:

1. Format: Check the structural validity and components of the code with BIC / SWIFT lookup.
2. Scheme: Verify exactly which scheme (SCT / SCT Inst / SDD Core / SDD B2B / VoP) the institution participates in with EPC participant lookup.
3. Reachability and availability: Confirm reachability for the payment type and channel, availability in the customer product, and operational status from your bank's current information; if the transaction is returned, interpret the reason code (CNOR/DNOR, etc.).

In short: BIC lookup verifies the format, the EPC Register verifies participation, and reachability becomes clear only with the payment result and the bank's confirmation. When you keep these three layers separate, you catch in advance most of the "looks valid but does not work" payment surprises.