Privacy policy

The public pages (home, documentation, capabilities, status, and these legal pages) require no account. BUMIT does not use advertising or third-party analytics on these pages. Fonts are loaded from Google Fonts.

The REST API is anonymous; no account or API key is required. Business identifiers are submitted in JSON request bodies and are used only to answer the request. Verification may look up authoritative external sources, such as the Swiss commercial register (Zefix), and may keep a stored copy of the public register record it receives. BUMIT also holds source datasets needed to answer checks, such as the sanctions list. Details of each source are in the documentation.

The MCP endpoint exposes one tool, verify_business, which runs the same verification path as the REST API. It requires no account. Each completed call records exactly one anonymous usage event (see below).

Each completed business verification records one anonymous structured usage event using a closed, predefined vocabulary (for example: input type, outcome, reason code, timestamp). The usage event does not record the submitted UID, business name, address, MCP client identity, session identity, IP address, or request headers.

Call counts are counts of calls; they are not counts of people or machines.

BUMIT records anonymous hourly aggregate counts of successful MCP protocol activity at its MCP endpoint, kept as two separate series: INITIALIZE and DISCOVER. Each stored row holds only the hour (UTC), the activity type and a count.

These are activity counts. They are not counts of users, people, identifiable MCP clients or sessions. The counters do not contain Claude identity, MCP client identity, session identity, IP address, request headers or tool arguments.

Anonymous verification usage events and aggregate MCP activity statistics are used to operate BUMIT, understand usage and adoption, analyse reliability, identify problems and improve the service.

Anonymous verification usage events and aggregate MCP activity statistics are normally retained for up to 365 days. They are periodically removed as part of operator maintenance; removal is not automatic, so records may remain somewhat longer until the next maintenance run.

BUMIT also keeps hourly request counts by fixed MCP method, HTTP status and a software category derived from the name declared during initialization. The name itself and raw request headers are not retained in these counters. Categories are self-reported, unverified and may be spoofed. Requests after initialization are not linked to it. These aggregate request counters have a 90-day retention target and are removed through operator maintenance, not automatically.

Additional Client Intelligence collection is currently disabled. If separately activated, it will retain only approved canonical software labels, bounded software-version categories, protocol-version categories, identification confidence and aggregate request/execution/business-outcome counts. User-Agent will be classified transiently into predefined software families; its raw value will not be stored. Arbitrary client names, credentials, business identifiers, raw IPs and IP hashes will not be retained.

This design associates an individual MCP request with its execution only. Separate requests remain UNATTRIBUTED. No protocol-session identifiers, session pseudonyms, persistent fingerprints or historical identities will be stored. An internal random observation key prevents duplicate telemetry delivery; genuine repeated executions remain separate. Identification is declared, inferred or unknown, never authenticated or verified.

Only authorized administrators, operators and viewers may read aggregate reports. Retention targets are seven UTC days for internal observation keys and 90 UTC days for aggregate facts. Automated daily cleanup and retention monitoring are being prepared offline, but are not deployed or scheduled. Cleanup removes only records older than the UTC-day boundaries; records on the cutoff day remain. The proposed fail-safe pauses additional collection if cleanup remains unresolved by the next daily window; recovery requires separate approval. Existing observation keys carry a server-generated timestamp for expiry, not a caller or session identifier. No collection will begin until the privacy disclosure, access controls, retention setup and production activation have been reviewed and authorized.

BUMIT does not currently maintain its own persistent application or security log store. Operational log messages are handled by the hosting infrastructure. BUMIT's logging layer is designed to drop or scrub business identifiers, names, addresses, credentials, request bodies and caller identity before log messages are emitted.

The hosting infrastructure may process technical connection information to deliver, operate and protect requests. Retention of these infrastructure logs is controlled by the hosting infrastructure under its own policies, not by BUMIT, and BUMIT does not state a deletion period for them.

Only BUMIT operators sign in, using an email address and password, to reach the administration console. Their email address and sign-in session are processed for that purpose. Public API and MCP use never requires sign-in.

Privacy-related questions can be sent to the address below.

Contact: support@bumit.ai