Disclaimer

DREWQ is an independent software tool developed and operated privately. It is not affiliated with, endorsed by, sponsored by, or operating on behalf of the National Identification Authority (NIA) of Ghana, the Government of Ghana, or any other government body or regulatory authority.

The Ghana Card is the ECOWAS biometric identity card issued by the NIA. DREWQ is a separately named developer tool designed to read and interface with that card standard. The use of the term "Ghana Card" is purely descriptive. No official relationship with the NIA is implied or should be inferred.

Any communications, data, or services provided through DREWQ are solely the responsibility of DREWQ and do not represent the views, policies, or positions of the NIA or any government institution.

Organisations intending to deploy identity verification services using Ghana Card data in Ghana are subject to regulatory oversight by the National Identification Authority. The NIA administers a formal verification services authorisation programme.

DREWQ does not substitute for NIA authorisation. Accessing DREWQ (including obtaining an API key) does not constitute regulatory approval to operate a verification service in Ghana. Your organisation is solely responsible for obtaining any and all required licences, authorisations, or approvals from the NIA and any other relevant authority before deploying a production verification service.

Failure to obtain the required authorisation may expose your organisation to legal liability under Ghanaian law. DREWQ accepts no responsibility for regulatory non-compliance on the part of its users.

DREWQ was built to give developers, entrepreneurs, and enterprises a practical way to explore and build with Ghana Card data. The Ghana Card (the ECOWAS biometric identity card issued by the NIA) represents a significant step forward in digital identity infrastructure for Ghana and the wider ECOWAS region. At the time of building, no publicly available developer tooling existed for working with the card.

Our goal is to lower the barrier to entry for builders who want to understand what the card contains, how it can be read, and what kinds of products and services it can underpin. Some of the use cases we see potential in:

• Banking & Fintech: account opening, cardless payments, and verified loan disbursement
• Transportation: cashless fare payment and verified ticketing for public and intercity transport
• Retail & Loyalty: loyalty programmes and age verification powered by the Ghana Card
• Hotels & Hospitality: instant guest registration and unified billing via card tap
• Payroll & HR: verified attendance tracking, ghost worker elimination, and wage disbursement
• Healthcare: patient registration, insurance claim verification, and prescription control
• Education: student enrolment, exam access, and fee payment tied to the Ghana Card
• Events & Access Control: non-transferable access passes for events, offices, and gated facilities
• Hardware & Embedded Systems: identity verification embedded into kiosks, POS terminals, and custom devices

DREWQ is intentionally designed as a developer-first API, so teams can prototype, test, and validate ideas before committing to the full regulatory pathway required for a production deployment.

There are real-world constraints to be aware of when building with DREWQ:

• Hardware dependency: Reading the Ghana Card chip requires a compatible contact or contactless smart card reader. Not all readers work out of the box. Driver support varies by operating system, and mobile NFC access is restricted on some platforms, notably iOS, where Apple limits NFC chip access to third-party developers.
• Basic Access Control (BAC):The Ghana Card chip is protected by BAC, which requires the document number, date of birth, and expiry date to be provided before the chip will respond to read commands. These values must be derived from the card's Machine Readable Zone (MRZ), either by optical scan or manual entry. If the MRZ is worn, damaged, or obscured, BAC authentication will fail and the chip cannot be read. Errors in any one of the three values, including date formatting mismatches, will also cause authentication to fail. Applications must handle BAC failure gracefully and should not store BAC key material beyond the duration of a single card session.
• Card data variability: The data stored on individual cards can vary between issuance batches and card generations. Some fields may be absent, differently encoded, or restricted depending on when and where the card was issued. Integrations should handle missing fields gracefully.
• Biometric data sensitivity:The Ghana Card chip stores biometric data including the cardholder's photograph and fingerprints. Unlike passwords, biometric data cannot be changed if compromised. Developers handling chip data carry a heightened duty of care and must implement appropriate security controls from the outset.
• Data protection obligations: Processing Ghana Card data is governed by the Ghana Data Protection Act 2012 (Act 843). Operators are data controllers and must have a lawful basis for processing, collect only what is necessary for their stated purpose, and be prepared to respond to data subject rights requests. Non-compliance carries legal liability.
• Passive Authentication and PKI: Fully verifying that chip data has not been tampered with requires passive authentication using Document Signer Certificates from the ICAO Public Key Directory (PKD). Ghana participates in the ICAO PKD, though its inclusion was initially subject to confusion regarding whether the certificate applied to the national ID card or the passport. PKD access for commercial purposes is currently restricted to the travel industry, meaning developers outside that sector cannot straightforwardly perform full passive authentication. Applications should communicate clearly what level of verification they are and are not performing.
• Restricted data groups: The chip stores data across multiple groups. Fingerprint data (DG3) is protected by Extended Access Control (EAC), a higher security layer beyond BAC, and access is limited to authorised border control applications. Developers cannot read DG3 fingerprint data through DREWQ. Applications should be designed around the data groups that are accessible and should not imply fingerprint-level verification to end users.
• Card-to-holder verification gap: A successful chip read confirms the data stored on the card but does not confirm that the person presenting the card is its legitimate owner. Without biometric matching against the chip photograph, a lost or stolen card could be used by someone else. Operators building high-stakes verification flows should layer additional cardholder confirmation steps beyond the chip read alone.
• Regulatory pathway: Organisations planning to deploy production verification services must engage directly with the NIA. Developers are encouraged to initiate that process early, as authorisation involves direct engagement with a government authority.
• Connectivity requirements: The DREWQ API requires an active internet connection. Offline or low-connectivity environments require additional architectural consideration.

DREWQ is provided "as is" and "as available" without warranties of any kind, express or implied. To the maximum extent permitted by applicable law, DREWQ and its operators, directors, and contributors shall not be liable for:

• Any regulatory penalties, fines, or legal consequences arising from a user's failure to obtain required NIA or other governmental authorisation
• Decisions made by any person or organisation based on verification results returned by DREWQ
• Loss of data, business, revenue, or reputation arising from reliance on DREWQ
• Interruptions, errors, or inaccuracies in the data returned from card reads
• Any indirect, incidental, consequential, or punitive damages of any nature

Nothing in this disclaimer limits liability that cannot be excluded under applicable law.

Nothing within DREWQ, including this disclaimer, the documentation, or any communications from DREWQ staff, constitutes legal, regulatory, or compliance advice. You should seek independent legal counsel before deploying any identity verification product or service, particularly one that processes biometric or sensitive personal data.

DREWQ makes no representations about the legal sufficiency of any verification performed through DREWQ for any regulatory, compliance, or contractual purpose.