BSA combines a public and a private blockchain into one hybrid system, maximising security and throughput at the same time. The private chain manages registered device data, generates the one-time authentication key (OTAK), and selects verification nodes at random to reach consensus. The public chain is the high-speed communication interface: it receives authentication requests from outside and delivers the Access Grant to the service provider.
FAQ
Frequently asked questions
The questions companies and institutions ask most when considering BSA — architecture, compliance, performance and industry-specific use.
The core of BSA
FIDO2 and similar schemes keep a private key inside the phone — precisely what an attacker goes after. BSA has no key and no password that could be stolen in the first place. At registration, the device's unique hardware integrity value is converted into a randomised device authentication credential and stored, split into fragments, across a distributed ledger. At login, several ledger blocks are combined at random to generate a one-time authentication key (OTAK) on the fly. Even if the ledger itself were taken, inferring its structure or mounting a credential-stuffing attack is mathematically impossible.
BSA runs two parallel verifications inside a single authentication request, within a very short window. The first — device integrity consensus — has the server send device data at random to multiple nodes, which confirm through a consensus algorithm that the connecting device is genuine. The second — OTAK integrity check — has randomly chosen nodes re-verify the OTAK delivered to the user device, confirming that nothing was intercepted or altered in transit. Once authentication succeeds, the OTAK used and the communication channel are discarded immediately, leaving no room for tracing or replay attacks.
BSA can serve as national integrated authentication infrastructure, not merely a single company's login. Banks, carriers and government portals may each sit in a different authentication domain, yet by mutual agreement they can share distributed ledger data securely. That lets one device carry a user into services across many institutions without a password — a genuinely hyper-connected SSO ecosystem.
Business environment and operations
In exactly those unstable network conditions, BSA is the only workable answer. Even where burner phones are common, it delivers financial-grade security of the highest global standard straight away.
The principle
SMS OTP roots its trust in a phone number on a SIM — something that can be cloned, which makes it useless where burner phones are common. BSA does not depend on the number at all. It binds the integrity value of the handset hardware itself together with biometrics into a blockchain node: a decentralised structure.
How it is built
When integrating with a carrier's HLR, the identifying value is mapped not to the SIM number but to a hash of the handset's own identifier — IMEI, MAC — and registered in the node ledger.
You keep your existing ID, safely and without friction. The moment a loss is reported, the old device authority is revoked permanently and remotely; a single identity check on the new device re-registers it as a secure authentication node.
The principle
Because authentication authority is never permanently bound to one handset — it follows a Proof of Authority model across the whole distributed network. A smart contract deletes the old authority, and a zero-trust architecture synchronises it to the new device only after strict distributed consensus.
How it is built
You wire a lost-device and re-registration pipeline API into the backend. When a loss is reported, that node's state in the ledger flips to Deactivated at once. When the user signs in from a new device and clears whatever second factor you specify — OTP, email — the new hardware hash is written to the ledger and the authority transfers across.
We hold live references at first-tier banks and major financial holding groups — the institutions with the strictest compliance demands. The practical ceiling on user count is, in effect, unlimited.
The principle
Unlike legacy systems, where every additional user piles load onto a central server, in BSA each user's phone acts as a node taking part in verification. As traffic grows, the network's consensus power grows with it — the architecture is self-scaling.
How it is built
Separate the client handsets (light nodes) from the backend verification servers (validator nodes) into a scale-out architecture, and let a load balancer distribute verification traffic dynamically.
Nothing in your existing infrastructure — core banking, legacy databases — has to be replaced or taken offline. BSA overlays lightly on top of what you run and goes live immediately.
The principle
Because the heavy blockchain mainnet core runs on our own separate backend, and the whole system is modularised as microservices: you connect only the interface layer, the API and SDK.
How it is built
Backend: a standard RESTful API talks to your servers — Java, C#, Node.js; the language does not matter. Frontend: an SDK supporting both native iOS and Android drops into your existing app as an in-app library add-on.
From requirements definition to launch, the project typically runs two to three months. You need assign only a minimal team.
The principle
Because the core authentication logic arrives as an already-proven package. You never have to think about backend logic — only the frontend integration — so the resource cost is extremely low.
How it is built
We supply the project manager and the integration engineers. On your side, the task force needs only one or two developers — in-house or contracted — to wire the SDK into your app, plus one planning or policy lead to decide the authentication scenario and its UX.
Cloud (SaaS) keeps initial infrastructure cost low and can go live quickly — though it can run into limits where national rules forbid data leaving the country. On-Premise is built inside your own data centre, giving complete control and a hard block on sensitive data crossing the perimeter, at the cost of upfront hardware spend and build time.
The principle
Cloud shares global infrastructure to maximise cost efficiency. On-premise builds an independent private blockchain network inside a bank's or an agency's own firewall, satisfying physical compliance requirements in full.
How it is built
The choice follows your own security policy. Lately, large institutions most often prefer a hybrid architecture: the verification core stays in-house while ordinary user traffic is distributed through the cloud.
Early models did see biometric sensor failures on low-cost handsets and access timeouts caused by unstable networks in developing markets. Both have since been solved at the system level.
The principle
Because uninterrupted global service means accommodating both device fragmentation and poor network conditions.
How it is built
Against device fragmentation: a fall-back pipeline switches automatically to our own PIN authentication the moment a handset sensor misbehaves. Against network latency: the payload of the server-to-server verification message (the OTA hash) is compressed aggressively, and an asynchronous algorithm lets a backend super-node complete consensus on behalf of a delayed peer.
For CTOs and CISOs
Entirely possible — and it is the enterprise hybrid architecture large financial institutions ask for most. You can run hundreds of virtual instances inside the bank private cloud and operate your own verification ecosystem under your own control.
The principle
Because a node in BSA does not have to be a physical phone. Any logical unit able to take part in authentication will do — the structure is deliberately flexible about form.
How it is built
Deploy multiple virtual-machine nodes on the internal network — a DMZ segment, for instance — using container tooling such as Docker or Kubernetes, and build them into an internal private consensus cluster.
There is no conflict at all; the design complies fully. When a customer closes their account, deleting the personal data in the institution's own central database satisfies every legal requirement.
The principle
Because the BSA ledger uses a zero-knowledge-proof distributed architecture in which not a single character of personally identifiable information — a name, a phone number — is ever written.
How it is built
Only meaningless hash values are ever written to the blockchain. Delete the customer database and the link between ledger data and a real person is severed — what remains on the ledger becomes safe digital refuse that can never be traced to an owner. No regulatory exposure is left.
Even the highest-privileged administrator cannot approve or tamper with an authentication alone. The structure makes it impossible.
The principle
Because it is key-less: unlike a conventional server, there is no answer sheet — no key ledger in a central database — for an administrator to read or alter.
How it is built
The final approval trigger fires only on the integrity value verified at the customer's own device node, together with a majority consensus among multiple nodes. A backend administrator simply has no switch to flip.
FIDO2 is a fine standard, but it carries two limits by birth: it must store a private key — the very thing attackers hunt — and it must lean on a large central server. BSA removes the private key altogether and turns the device into a node. It is the next generation beyond FIDO2.
The principle
Key-less security: FIDO2 stays exposed to sophisticated targeted attacks aimed at the key held on the phone. BSA never generates a private key to steal, and distributed consensus removes the single point of failure. Recovery integrity: when a FIDO2 device is lost, recovery ultimately falls back on weaker channels such as SMS or email. BSA revokes the authority outright on the blockchain, and re-registration also runs through consensus, so the security bar never drops.
How it is built
Instead of adding more heavy FIDO central servers, the architecture is replaced by a light process: the client's hardware identification value goes straight to the BSA distributed ledger mainnet to seek consensus.
Heavy traffic and data load
There is no slowdown. The scaling works the other way round: the heavier the traffic, the faster and steadier verification becomes. Even at extreme peaks, response stays in the millisecond range.
The principle
A central server buckles under a rush of traffic. In BSA the phones themselves share the computation, so ten million users bring ten million verification nodes with them. The load cancels out — the architecture is self-scaling.
How it is built
A sharding architecture divides the node pool into shards that process transactions in parallel, while an L4/L7 load balancer routes inbound traffic automatically to the best-placed shard.
There is no risk of data growth overloading the core system. Core banking takes no load at all, and after decades of operation the mainnet ledger stays light and fast.
The principle
The authentication network and the core banking ledger are fully decoupled and run in parallel. The BSA ledger also carries no heavy data — only a device integrity hash of a few dozen bytes and an approval state value. It is a purpose-built, ultra-light structure.
How it is built
Communication with core banking is asynchronous, and the mainnet applies state snapshotting and archiving. Only the current state needed for live verification stays in high-performance memory; older data is compressed and offloaded on a schedule.
Data usage on the user's device is effectively nil, and consensus completes instantly even on sub-3G bandwidth without straining the link.
The principle
Because nodes never exchange whole original data during consensus — only mathematically compressed, ultra-light signature fragments.
How it is built
Client and backend talk over an ultra-light bidirectional gRPC protocol rather than heavy HTTP, minimising packet overhead; if the link drops, the pipeline re-requests only the lost hash.
Industry use and future scale
FIDO2 and its peers perfect the centralised Web 2.0 world; they do not fit the decentralised Web 3.0 one now arriving. BSA accommodates today's environment while acting as a native bridge that carries you into Web 3.0 without a rebuild.
The principle
Because BSA is not a login tool that happens to use a chain — it is distributed ledger technology by birth, carrying the self-sovereign identity principle that control over data belongs to the user's own device.
How it is built
The system is designed so that when a government later launches national digital-asset programmes — a CBDC, electronic voting — connecting to the API of the BSA network already in place extends it directly into digital wallet verification and smart contract execution infrastructure.
Handset hardware integrity is bound together with biometrics, shutting out phishing apps and man-in-the-middle interception at the root.
How it is built
Backend: run BSA nodes on the bank internal network, separated from the core banking ledger. Frontend: embed our SDK inside the existing banking app so the entire approval finishes with one biometric touch, without ever leaving the app.
Built on zero-knowledge proofs, it never pools sensitive national ID numbers on a central server — so the risk of a nationwide database breach disappears structurally.
How it is built
Backend: connect the mainnet to the government's integrated authentication gateway to build SSO with no centralised authentication server. Frontend: embed BSA as the core inside the official national digital wallet and ID app for immediate integration.
Authentication rests on the device hardware's own value rather than an easily cloned USIM number, disarming SIM-swap financial fraud.
How it is built
Backend: when integrating with the subscriber server (HLR), map the handset MAC/IMEI values to build the ledger. Business: expose the completed BSA engine as an Open API and offer it to outside banks and e-commerce firms as a metered B2B authentication service.
The key-less structure removes both the password and the private key an attacker would take, so phishing and credential stuffing cannot happen at all.
How it is built
Backend: as a SaaS subscription, the BSA plug-in connects straight into the standard SAML or OAuth module of your ERP. Frontend: apply the SDK to your groupware app or storefront app to remove the password field entirely and give users a cleaner way in.
Is your question
not on this page?
A specialist will answer for your specific environment.