Account numbers

How Norwegian account numbers are structured, and what validation can prove.

Structure

A Norwegian account number (BBAN) is always 11 digits:

8601 11 17947
└──┘ └┘ └───┘
  │   │    └── account number
  │   └─────── account group
  └─────────── bank identifier ("registernummer")

The first four digits are the bank identifier. Bits publishes the mapping from those digits to a BIC, and that mapping is what /v1/banks/lookup reads. A bank typically owns many identifiers — Danske Bank alone has over 70.

The last digit is a MOD-11 check digit over the first ten, using the weights 5 4 3 2 7 6 5 4 3 2. Some ten-digit prefixes produce a remainder of 1 and therefore have no valid check digit; those account numbers are never issued.

IBAN

The Norwegian IBAN is the BBAN with a country code and two MOD-97 check digits:

NO93 8601 1117 947
└┘└┘ └─────────────┘
 │ │        └────── the 11 digit BBAN
 │ └─────────────── MOD-97 check digits
 └───────────────── country

Both directions are handled for you — POST either form to /v1/accounts/validate and you get both back.

Why POST

The account number goes in the request body, never in the URL. A URL ends up in access logs, proxies, browser history and error trackers, and an account number tied to a person is personal data. Responses are sent with Cache-Control: no-store.

In a browser form you often don’t need to send the full number at all: validate it locally with @kontosjekker/core and look the bank up by its first four digits, GET /v1/banks/lookup?clearingCode=8601. That response is public and cacheable. The React component works this way.

What validation proves

It does not prove that the account exists, is open, or belongs to a particular person. There is no public register in Norway that can answer that; only the receiving bank knows. Use validation to catch typos before a payment file is submitted, not as an identity check.

Error codes

When account.valid is false, account.error.code is one of: