BankCodeKit

Security

Security and Local Processing

BankCodeKit is designed so payment-code checks run in the browser. This page explains what the tools do with user-entered IBANs, BICs, invoice details, CSV rows, and payment references.

Written and maintained by BankCodeKit. Content review: .

Browser-Local Tool Logic

Tool inputs are processed by client-side code in the browser. IBAN normalization, checksum review, BIC format parsing, SEPA country lookup, invoice formatting, and CSV export use local code and local reference data.

The page itself still arrives over the network: the browser downloads HTML, CSS, JavaScript, fonts, icons, and the static reference data needed by the tool. Local processing means the value entered after the page loads is evaluated by that downloaded code without an account-lookup request to BankCodeKit, a bank, or a payment API.

Technical processing boundary

Technical payment-input processing boundary
Stage Browser activity Network transmission Browser retention
Page load Downloads static HTML, CSS, JavaScript, fonts, icons, and reference data. Normal static-asset requests occur before payment details are entered. No payment input exists to retain.
Typing or pasting Keeps the current value in the active page state. The entered value should not appear in a request, URL, or analytics payload. BankCodeKit does not write the value to cookies, localStorage, or sessionStorage.
Run format check Normalizes characters and applies local reference and checksum rules. No bank, account, directory, or payment API lookup is made. The result remains in the current page state.
Show result Renders format findings in the same browser tab. The displayed value should remain absent from external requests. A reload clears the BankCodeKit result state.
Create CSV Builds the requested export from the current bulk-check rows. BankCodeKit does not upload the rows to generate the file. The downloaded file persists under the device and storage-provider controls.

How to verify local processing

You can inspect the behavior with browser developer tools and a synthetic test value. Open the Network panel, clear existing requests, enter the test value, and run the check. The tool should calculate and display its result without creating a request that contains the value. Also confirm that the value does not appear in the address bar or page URL.

  1. Use a published synthetic value from the Validation Test Cases page, never a real account.
  2. Clear the Network panel immediately before the tool interaction.
  3. Run the check and inspect request URLs, query strings, request bodies, and analytics payloads.
  4. Inspect cookies, sessionStorage, and localStorage in the Application or Storage panel.
  5. Reload the page and confirm that the previously entered value is not restored by BankCodeKit.

This inspection documents the site implementation boundary. Browser extensions, clipboard managers, operating-system history, screen recording, malware, and device administration are outside that boundary and can still observe data on the device.

Where Tool Inputs Are Not Sent

  • BankCodeKit servers or external APIs.
  • Page URLs, query strings, or route parameters.
  • Analytics events or advertising events.
  • Advertising scripts or ad request data.
  • Browser localStorage, sessionStorage, or cookies.
  • Server logs controlled by BankCodeKit application code.

CSV And Clipboard Handling

Bulk IBAN CSV output and copy buttons can contain payment details the user entered. These actions are local browser actions, but the files or copied text can still be sensitive after they leave the page. Handle exported CSV files and copied payment details carefully.

A CSV download becomes a normal file that may be indexed, backed up, synchronized, emailed, or retained after the browser tab closes. Copied text may remain in clipboard history. Minimize the data you include, restrict file access, and delete exports according to your organization or device retention rules.

Public or shared computer warning

Do not enter sensitive payment details on a public or shared computer. Local browser processing does not protect against another user, administrator, installed extension, clipboard history, synchronized download folder, or monitoring software on that device. Use a trusted device and close the page when the review is complete.

Advertising And Analytics Guardrail

If advertising or analytics is used on the site, tool input values must stay out of analytics events, ad requests, ad scripts, URLs, storage, logs, and cookies. Ads should not be placed inside tool forms, result cards, warnings, copy buttons, download buttons, or navigation. Display-ad eligibility is route-gated so tool pages stay separated from ad slots even if display ads are enabled later.

Format-Only Limitation

Local processing improves privacy, but it does not turn format checks into account verification. BankCodeKit does not confirm account existence, account ownership, bank connectivity, sanctions status, fraud risk, payment readiness, or payment success.

A local failure can point to an unsupported country, incorrect length, disallowed character, or inconsistent checksum. A local pass means only that the visible value matched supported reference rules. Confirm the payee, invoice source, amount, currency, reference, bank instructions, and fraud risk through a trusted recipient, bank, or payment provider before sending money.