T5-ABIS BE Automated Biometric Identification System
T5-ABIS Automated Biometric Identification System Biometric Engine is a mission-critical multi-biometric search engine for Nation level Largescale ID projects that allows “on-the-go” identification of a person by face, fingerprint, and iris. All 3 of these core technologies have been fully developed in-house. T5-ABIS BE is designed around secure lifecycle standards and includes built-in security. Data at rest and in transit is encrypted and APIs are protected by authentication and authorization. Application data stores are decoupled by design, and we can implement centralized access to ensure privacy and security. T5-ABIS BE offers several key benefits. It is cost-efficient because it uses commercial off the shelf infrastructure, small hardware footprint, and centralized system management. The availability of a REST API as the key interface to T5-ABIS BE ensures that any required integration is effortless and fast.
T5-ABIS. BE has been successfully used in national scale level projects around the world. Currently more than 320 million active identities are managed in global projects, and more than 200,000 transactions are processed by T5-ABIS BE every day. T5-ABIS BE is designed to grow with your expanding needs without an impact on performance, speed and accuracy. Thanks to built-in redundancy in the T5-ABIS BE open architecture, single point of failure is avoided, and system downtime is reduced to a minimum. T5-ABIS BE is designed to be implemented in a variety of legal and civil sectors requiring accurate identification, recognition and verification including access control, law enforcement, ID management, social inclusion, and immigration and passport control.
The multi-modal biometric capabilities of T5-ABIS BE along with the benefits of its architectural design can be tailored to meet the growth and performance requirements of each customer. The following describes the broad classifications of the modules available for individual solutions.
The Enrolment application is device vendor agnostic and will obtain all recommended demographics of each individual and capture biometric data per global standards. The data will be processed (finger slap segmentation, iris encoding, face formatting and quality check), checked for quality, and approved by the operator. The lossless images will be packaged and transferred to the backend application.
Data from the enrolment stations will be processed by the middleware application via the interfaces and business logic in workflow engine, and then sent to the matching environment for De-duplication. To keep the footprint of the system small and manageable, separate repositories with identical data for De-duplication and Authentication (verification) are proposed. This will keep the traffic separate for these two functionalities each of which has significantly different throughput volumes and process intensity. The De-duplication component will determine unique identities, and the matching environment will use them to populate the authentication repository. In this way the very high volume of authentication with lighter per transaction resources help to keep the overall matching environment small. The middleware application will interface with the Biometric Engine via REST API. The De-duplication engine will process the requests sent via REST API for De-duplication to determine the uniqueness or non-uniqueness of biometric probes. Business logic will drive the decision to search a single or all biometric modalities for the De-duplication task in order to achieve the highest possible accuracy and throughput performances. Matching results up to a certain rank (configurable) will be returned with an individual matching score per ID.
Authentication will be carried out using the TECH5 Multi-Biometric Authentication Platform (T5-MBAP), a software solution with various workflows to handle user requests. Request for authentication will be processed by T5-MBAP REST API calls directly invoked by the middleware or authentication web service. The ISO or proprietary templates for up to ten fingerprints are generated during the enrolment/ insert call and stored in the Authentication Data store. The templates allow for biometric verification and return the result in the API response. For Face and Iris authentication transactions only proprietary templates are supported due to the lack of any standard for templates. If authentication by 1:1 verification fails, business logic can use the same probe to initiate a 1:N search against the De-duplication repository to determine if the individual already exists under another identity or if fraud has occurred.
Search of one identity will be carried out across N already enrolled identities in the database to identify a person and delivers results real-time using T5-ABIS BE.
In a National ID database, an individual should have only one identity. National ID databases involve millions to billions of records and duplication of identities poses a big challenge for such databases. When enrolling new users, each entry must be compared against the entire database (N: N) to check for duplicates. When authenticating, it is only necessary to check whether a given set of credentials exists in the database (1: N or 1:1).
The data collected during registration or enrolment is automatically compressed, encrypted by the enrollment software, and submitted to a central repository, sometimes referred to as the National Population Register or the National Identity Register (NIR), where it undergoes several automated steps of processing and validation. First, templates are generated from the biographical data or biometric images and then exhaustively searched against all previously enrolled templates associated with known identities. If no match is found, the identity is considered new and is passed on to the next phase for further validation. If a match is found, it means that the identity was previously enrolled (duplicate). If the decision falls in a grey area, a trained operator validates whether the match suggests fraud and takes appropriate action to prevent it from registering.
This de-duplication process ensures the uniqueness of each record in the NIR. A de-duplicated identity then undergoes a mostly automated process of vetting, proofing, and linking to the claimed social or legal identity, using metadata collected at the time of enrolment. Alternatively, an identity examiner analyses the social footprint of the claimed identity by examining evidence from breeder documents as well as by cross-referencing with other external databases, including property registers, voter registers, civil registers, and police records. When the examiner is satisfied that the identity is real and is linked to a socially existing identity, it may be issued a UIN and is added to the NIR. From there on, this identity is fixed and is bound to the NIR for life.
T5-ABIS BE ensures one person has only one identity in the database. The enrolment station at the frontend captures biometric data and the AFIS/ABIS at the backend de-duplicates that data to ensure uniqueness of each record in the identity repository. ABIS can perform de-duplication across multiple biometric modalities.
Nation-wide T5-ABIS BE provides a single source of information on which a population can rely to establish their ID. In this way, ABIS eliminates multiple isolated ID systems, waste, and inconsistent standards that prohibit data sharing.
The massive redundancy built into the system architecture ensures that there is no single point of failure and offers the added benefit of supporting concurrency and high throughput, making the system both cost-effective and highly reliable. Redundancy ensures that there is no loss of data and guarantees system availability with minimal reduction in performance until the failed component is repaired. In the event of multiple failures, the system throughput, but not latency of discrete transactions, will be decreased while the matcher faults are offline, ensuring that production is never halted. T5-ABIS BE architecture and design principles include:
T5-ABIS BE is designed to allow easy upgrades of the underlying core biometric SDK with minimum changes.
The application discovers services dynamically rather than relying on hard-coded dependencies.
The application consumes and exposes web services with APIs discoverable at runtime. The structure incorporates as much as possible small, stateless components designed to scale out. Services for transaction processing, template creation and storage can be made stateless and launched in AWS auto scaling group.
The application is instrumented and exposes metrics and management interfaces. These are required for performance measurement and tracking. The log format for each component is standardized for log aggregator such as logstash / sumologic that can do the analytics and performance measurements.
The application is based on secure lifecycle standards and includes built-in security. Data at rest and in transit can be encrypted. APIs are protected by authentication and authorization.
Data stores are decoupled by design to reduce the impact of data breaches.
The system limits/reduces the need for access to all nodes for manageability/operation purposes. For example, centralized configuration management, log aggregation and monitoring hooks reduce the need for accessing individual nodes, thus reducing security risk.
The design minimizes costs due to bandwidth, CPU, storage consumption, and I/O requests. The model with template creation to the edge reduces central DC infrastructure needs.
Centralized configuration management helps with easy and fast configuration changes reducing the risk of misconfigurations especially when many nodes must be configured. Configuration settings can be versioned and controlled and changes can be audited.
The application makes no assumptions about the underlying infrastructure, using abstractions in relation to the operating system, file system, database, and so on. T5-ABIS BE incorporates technologies that are platform and OS independent.
Resiliency is designed into the application so that failures in the infrastructure are handled fluidly without interruption of service. Failure in components will be handled by redundant components and graceful reduction in capacity vs. interruption. If components are abruptly broken (disappear in case of cloud), new component nodes can be rapidly provisioned using provisioning/deployment tools like Docker/Ansible.
The T5-ABIS BE principles of distributed computing allow for efficient scaling to meet the performance and availability SLAs. There are considerations for both vertical and horizontal scalability. Special consideration is given to components like matcher nodes that cannot simply follow standard design principles.