FAQ
Frequently Asked Questions
The questions enterprises and institutions most often ask when evaluating BSA — from architecture to compliance, performance, and industry use cases.
BSA Core Architecture
What is the Hybrid Blockchain Architecture?
BSA adopts a hybrid system where public and private blockchains are organically combined, maximizing both security and processing speed. The private blockchain manages registered users' device data, generates One-Time Authentication Keys (OTAK), and randomly selects validator nodes to reach consensus. The public blockchain is a high-speed communication interface that receives authentication requests from external users and delivers the Access Grant to the Service Provider.
What is a 'Key-less' Distributed Ledger without a Private Key?
While standards like FIDO2 store a 'private key' inside the smartphone that becomes a target for hackers, BSA completely eliminates the existence of any key or password that can be stolen. When a user registers, the terminal's unique hardware integrity value is converted into 'Randomized Device Authentication Credentials' and fragmented across the distributed ledger. Upon login, multiple data blocks are randomly extracted and combined to dynamically generate an OTAK, making it mathematically impossible to infer the structure or launch Credential Stuffing attacks even if the ledger is compromised.
What is the Double Verification and Trace-less Mechanism?
BSA performs two parallel verifications in a very short instant for a single authentication request. The 1st Verification (Device Integrity Consensus) has the server randomly transmit device data to multiple nodes to verify, via a consensus algorithm, whether the connecting phone is the original device. The 2nd Verification (OTAK Integrity Check) has random nodes re-verify the OTAK sent to the user's device to confirm the data was not intercepted or altered in transit. Once authentication completes, the OTAK and communication channel are immediately discarded, making any tracking or reuse attack impossible.
What is Multi-Domain Integration and Infinite Scalability?
BSA can transcend single enterprises to form a national 'Integrated Authentication Infrastructure'. Even if different service providers such as banks, telecoms, and government portals belong to different authentication domains, they can safely share the central server's distributed ledger data upon mutual agreement. Through this, users can access various institutional services without passwords (SSO) using a single device.
Business Environment & System Operation
In countries where prepaid SIM cards are frequently changed or burner phones are rampant, is BSA authentication still meaningful?
Rather, in such unstable communication environments, BSA is the only solution and the most powerful alternative. It can instantly implement global top-tier financial security even in a burner-phone environment.
Existing SMS authentication (OTP) relies on replicable 'phone numbers (SIMs)' as the basis of trust, rendering it useless in a burner-phone environment. In contrast, BSA is a decentralized structure that does not rely on numbers but binds the smartphone's 'hardware device itself' into a blockchain node by combining its integrity value and biometric information.
When integrating with a telecom's HLR (Home Location Register), the system maps the identification reference value to the hash of the terminal's unique identifier (IMEI, MAC, etc.) instead of the SIM number, and registers it in the node ledger.
When a phone is lost or changed to a new device, how can the existing ID be used identically?
The existing ID can be safely continued without any issues. Upon reporting a loss, the authentication authority of the old device is permanently revoked remotely, and after a single identity verification on the new device, it is re-registered as a secure authentication node.
Authentication authority is not permanently bound to a specific device but follows the 'Proof of Authority' method of the entire distributed network. A Zero Trust architecture deletes the existing authority via a smart contract and synchronizes it to the new device through strict distributed consensus.
A 'device loss and re-registration pipeline' API is configured in the backend. Upon a loss report, the node's status value in the ledger is immediately set to 'Deactivated'. When logging in with a new device, after passing secondary authentication (OTP/Email, etc.) designated by the client, the new hardware hash value is updated in the ledger to transfer the authority.
Based on adoption cases, what is the maximum number of users that can be accommodated when using smartphones as nodes?
We hold successful references of adoption in Tier-1 financial institutions (commercial banks, etc.) and large financial holding companies that demand the strictest security compliance. The maximum number of users the system can accommodate is virtually 'Infinite Scalability'.
Unlike legacy systems where the load on the central server explodes as users increase, BSA functions with each user's smartphone acting as a node participating in verification. It possesses a Self-Scaling structure where the network's consensus power increases proportionally as traffic (users) increases.
A Scale-out architecture is configured by separating the client terminal (Light Node) group from the backend verification server (Validator Node) group, and a load balancer dynamically distributes the verification traffic.
What are the Tech Stack conditions and integration environment for system implementation?
There is absolutely no need to completely replace or suspend the client's existing infrastructure (Core Banking, legacy DB, etc.). It is instantly deployed as an Overlay on top of the existing system.
The heavy and complex blockchain mainnet core engine runs independently on our backend, and it is strictly modularized into a Microservices Architecture (MSA) where the client only needs to connect the interface layer (API/SDK).
Backend: Communicates with the client's server (language-agnostic: Java, C#, Node.js, etc.) through standardized RESTful APIs. Frontend: Provides SDKs supporting both iOS and Android native environments, added as a library (Add-on) inside the client's existing app (In-App).
What is the expected timeframe, cost, and manpower required from the client side for system implementation?
From requirements definition to commercialization, it is usually completed as an ultra-short-term project taking 2 to 3 months. The client only needs to assign a very minimal workforce.
The core logic of the authentication process is provided as a pre-verified package. The client side does not need to worry about backend logic and only performs frontend integration, resulting in extremely low resource consumption.
We dispatch a Project Manager (PM) and integration support engineers. The client only needs to assign 1 to 2 internal (or external) developers to integrate the SDK, and 1 planning/policy manager to determine the authentication scenario (UI/UX).
What are the pros and cons of the Cloud (SaaS) model versus the On-Premise model when configuring the server environment?
Cloud (SaaS): Initial infrastructure setup costs are low, and ultra-short-term deployment within 2 weeks is possible. However, there may be constraints depending on the country's regulations on 'prohibition of cross-border data transfer'. On-Premise: As it is built directly within the client's own data center, perfect control and prevention of sensitive data leaks are possible. However, initial hardware acquisition costs and setup time are required.
The cloud aims to maximize cost efficiency by sharing global infrastructure resources, while On-Premise aims to 100% satisfy physical regulatory compliance by constructing an independent private blockchain network within the firewalls of financial/public institutions.
It can be selected according to the adopting institution's security policies. Recently, large institutions most prefer the Hybrid architecture, where the verification core is kept internal but general user traffic is distributed and processed in the cloud.
What is the status of expanding industries outside the financial sector, and what is the primary authentication method for each client?
It is expanding into a universal security model handling millions of traffic at the national-infrastructure scale, such as smart cities, telecom networks, and national defense. Users adopt 'Passwordless Multi-Factor Authentication (MFA)' as the standard, using only biometric authentication (Fingerprint, Face ID) without complex password inputs.
While the user only scans their fingerprint in just 1 second, the backend simultaneously performs terminal integrity verification and ledger consensus, achieving 'the most intuitive User Experience (UX)' and 'the highest military-grade security (Backend)' at the same time.
It first performs local authentication by calling the device's FIDO API (biometric recognition), then transmits hash data—combining that result with the terminal's unique identifier—to the BSA blockchain network for final approval (2nd step).
What are the Quality Control (QC) issues or Access Error cases that mainly occur during system operation, and what are the solutions?
In early models, there were issues with biometric sensor malfunctions on low-end terminals and access timeouts due to unstable networks in developing countries, but these have now been completely overcome systemically.
In a global service environment, seamless service is only possible by accommodating both device fragmentation and poor network environments.
Device Fragmentation Defense: Built a Fall-back bypass pipeline that immediately and automatically switches to self-PIN code authentication upon a terminal sensor error. Network Latency Defense: Applied an asynchronous communication algorithm that extremely compresses the payload of the server-to-server verification message (OTA Hash), and allows backend 'Super Nodes' to complete the consensus on behalf of the user when delays occur.
What are the practical use cases being promoted in the global market?
We are actively undertaking national network infrastructure enhancement projects for state-run banks, commercial banks, and state-owned telecom companies in various countries, as well as large-scale security convergence projects with mega global energy corporations.
Emerging countries are taking a 'Leapfrogging' strategy, skipping the heavy legacy systems of advanced nations and jumping straight to the latest mobile and blockchain infrastructure. BSA is the optimal solution for building national-level security infrastructure in the shortest time without massive central network investment costs.
It is constructed by building the BSA private mainnet core in the central data centers of local government ministries and state-run institutions, and distributing it as an API Gateway to affiliated public institutions and financial companies to create a national integrated authentication network.
CTO/CISO Deep Defense
[Node Configuration] Is it possible to implement Virtual Instances within a financial institution's internal network to operate as proprietary nodes without relying solely on external phones?
It is perfectly possible and is the 'Enterprise Hybrid Architecture' most strongly demanded and preferred by large financial institutions. An independently controllable verification ecosystem can be established by launching hundreds of virtual instances within the bank's private cloud.
A node in the BSA system does not necessarily have to be a 'physical smartphone'. It has a flexible structure that does not discriminate in form as long as it is a logical unit capable of participating in authentication.
Implemented by deploying multiple Virtual Machine (VM) nodes within the internal network (DMZ, etc.) using container tools like Docker or Kubernetes, and establishing an internal private consensus cluster comprised of these nodes.
[Compliance] Is there any legal conflict with the immutability of a blockchain ledger when a request for information deletion (Right to be Forgotten) is made under local personal information protection laws?
There is no conflict whatsoever, and it complies 100% with legal regulations. When a customer withdraws, simply deleting the personal information within the financial institution's central DB finalizes all legal requirements.
The BSA ledger adopts a 'Zero-Knowledge Proof' based distributed ledger architecture where sensitive PII such as the customer's name or phone number is never recorded, not even a single character.
Only meaningless 'hash random numbers' are recorded on the blockchain. If the client's DB is erased, the link that maps the ledger data to the actual individual is severed, turning the ledger data into secure digital garbage that can never find its owner, thereby completely blocking any potential for regulatory violations.
[Insider Threat Defense] Is defense possible if an internal system administrator (Super Admin) with the highest authority maliciously attempts to approve authentication?
Even for a super administrator, unilaterally approving or forging/falsifying authentication is structurally impossible, providing an impenetrable defense.
It is a Key-less structure where an 'Answer Sheet (Key Ledger)' that an administrator can look into and manipulate in a central DB—like in legacy servers—does not exist.
The system's final approval trigger must be executed solely through the data integrity verification value of the 'customer's own terminal node' and a majority consensus among multiple nodes, fundamentally blocking any means for a backend administrator to arbitrarily flip a switch.
[Technological Gap] What is the decisive advantage of adopting BSA instead of FIDO2, which is currently widely used as a biometric authentication standard?
FIDO2 is excellent, but it carries the inherent limitation of having to store a 'private key' that becomes a hacking target, and relying on a massive 'central server'. BSA is a Next-Gen technology that completely shatters the limitations of FIDO2 by entirely eliminating the private key itself and turning devices into nodes.
Security (Key-less): FIDO2 is exposed to advanced targeted hacking aimed at the 'key' stored on the phone. BSA eliminates the Single Point of Failure (SPOF) through distributed consensus, as no 'private key' to be stolen is ever generated. Recovery Completeness: When a device is lost, FIDO2 ultimately requires bypass authentication (Fallback) using vulnerable methods (SMS/Email). BSA flawlessly revokes authority on the blockchain and maintains peak security through consensus even upon re-registration.
Instead of expanding heavy FIDO central servers, the architecture is replaced with a lightweight process that directly transmits the client's hardware identification computation value to the BSA distributed ledger mainnet to seek consensus.
Large-scale Traffic & Data Load Defense
[TPS Degradation Defense] Does the bottleneck phenomenon or TPS degradation unique to blockchains occur when traffic explodes due to massive concurrent user access, such as on payday?
Delays do not occur; instead, it demonstrates a paradoxical scalability where the system's verification speed and stability increase as traffic surges. It guarantees a comfortable speed at the 1-millisecond (ms) level even during extreme peak times.
When users surge, central servers go down due to computational limits. However, since BSA uses smartphones themselves as nodes that share the computation, if users increase to 10 million, the verification node capacity to handle it also concurrently increases to 10 million, resulting in a Self-Scaling structure where the load is perfectly offset.
Introduced a 'Sharding Architecture' that divides the entire node group into Shards to process transactions in parallel, and automatically distributes inbound traffic to the optimal shard via load balancers (L4/L7).
[Storage Load Defense] If users increase to tens of millions and the system operates for years, won't the mainnet ledger data grow exponentially and burden the Core Banking system?
There is absolutely no concern about core system overload due to data explosion. It does not put any load on Core Banking, and even after decades of operation, the mainnet ledger maintains an optimal, light, and fast state.
The authentication network (BSA) and financial ledger (Core Banking) architectures are completely decoupled and processed in parallel. Moreover, the BSA ledger contains no heavy data and is a purpose-built ultra-lightweight structure where only 'terminal integrity hashes' of a few tens of bytes and approval status values are recorded.
It communicates asynchronously with Core Banking and applies 'State Snapshot' and 'Archiving' technologies to the mainnet. Only the latest state values necessary for real-time verification are kept in high-performance memory, and past data is compressed and periodically off-loaded.
[Network Bandwidth Control] If numerous terminal nodes communicate with each other in a country with poor communication infrastructure, won't it consume excessive network bandwidth and cause load?
The consumption of the user terminal's data (plan) is virtually 0%, and immediate authentication consensus is possible without communication load even in ultra-low bandwidth environments below 3G.
During consensus between nodes, the original data is not transmitted entirely; instead, an optimized communication method is used where only mathematically extremely compressed, ultra-lightweight signature data fragments are exchanged.
During communication between client and backend, an ultra-lightweight bidirectional protocol based on gRPC is applied instead of heavy HTTP to minimize packet overhead, establishing a pipeline that immediately re-requests only the lost hashes even if communication is disconnected.
Future Vision & National Infrastructure Scalability
[Paradigm Shift] In the transitional period where the IT ecosystem shifts to Web 3.0, what is the macro reason an adopting country should choose BSA as national infrastructure rather than existing systems?
FIDO2 and the like are merely the completion of a 'Web 2.0 (centralized)' environment — a model of the past that does not fit the coming 'Web 3.0 (decentralized)' ecosystem. BSA is the best 'Native Bridge' that embraces the existing environment while letting you leap straight into the Web 3.0 era without a separate rebuild.
This is because BSA is not a 'simple login tool' but is, by its very nature, a Distributed Ledger Technology (DLT). It fundamentally embodies the Self-Sovereign Identity (SSI) philosophy where data control belongs to the user's device.
When a local government later develops national digital asset initiatives such as CBDC (Central Bank Digital Currency) or e-voting, simply integrating the API of the already-deployed BSA authentication network lets it expand infinitely into a 'digital wallet verification and smart-contract execution infrastructure'.
Industry-Specific Use Cases
Finance: 'Media-less Absolute Authentication' for high-value transfers and non-face-to-face lending
Because terminal hardware integrity is combined with biometric information, phishing apps and Attacker-in-the-Middle (MITM) hacking attempts are fundamentally blocked.
Backend: Configure BSA nodes on the financial institution's internal network, decoupled from the Core Banking ledger. Frontend: Embed our SDK inside the existing banking app so the entire approval completes with a single biometric scan without leaving the app.
Government: National integrated Digital ID (DID) and ultra-fast SSO login
Designed on a Zero-Knowledge Proof basis, sensitive data such as national ID numbers is not aggregated on a central server, so the risk of nation-scale mass DB hacking structurally disappears.
Backend: Integrate the mainnet with the government's unified authentication gateway to build an SSO system without a centralized authentication server. Frontend: Embed BSA as the core inside the government's officially distributed 'national integrated digital wallet/ID app' for instant integration.
Telecom: SIM-swapping defense and next-generation 'Identity Provider (IdP)' business
By using the 'device hardware unique value' rather than the easily replicable USIM number as the basis of authentication, SIM-cloning financial crime is completely neutralized.
Backend: When integrating with the subscriber server (HLR), map the terminal's unique MAC/IMEI value to configure the ledger. Business: Convert the built BSA engine into an Open API to provide paid (B2B) authentication services to external banks and e-commerce companies.
General Enterprise: Internal Zero Trust and B2C e-commerce churn prevention
As a Key-less structure that completely eliminates the 'password' and 'private key' a hacker would steal, phishing and Credential Stuffing attacks cannot occur.
Backend: As a SaaS subscription, instantly connect a BSA integration plugin to the standard SAML or OAuth module of the internal ERP system. Frontend: Apply the SDK to internal groupware mobile apps or shopping-mall apps to remove password fields and deliver a smooth UX.
Have a question that isn't answered here?
Our specialists will tailor the answer to your environment.
Contact Us