mObywatel with the Eximee Low-Code Platform

Tomasz Ampuła
Published 12/10/2023

Since July 2023, Polish citizens have been able to use a new type of identity document called mDowód, which is recognized on par with a plastic card. Since September 1, banks are required to accept mDowód in the mCitizen app. In practice, this means that banks need a system that allows customers to digitally verify their identity at the bank’s branches.

Eximee Low-Code Development Platform and mObywatel app

We have developed a set of tools to make it easier for banks to implement identity verification using mDowód:

  1. Eximee mObywatel Component – a GUI element that provides an employee with a front end for identity verification. It can be embedded in various bank systems.
  2. Eximee mObywatel API – an intermediary layer between the ministerial Back System installed in the bank’s infrastructure and front-end modules.

We have embedded them in the Eximee Dashboard, one of the Eximee Low-Code Platform modules.

The identity verification process proceeds securely according to the following scenario:

  1. A customer at a branch informs an employee that they would like to identify themselves with an electronic mDowód.
  2. The employee initiates verification of mDowód and displays a QR code to the customer on a tablet or computer screen.
  3. The customer scans the QR code in the mObywatel application and confirms the transfer of a specific set of data to the bank.
  4. The transferred data set is presented to the employee whose responsibility is to verify that the photo matches the customer’s facial features.
  5. After positive verification of the customer’s identity, the bank acquires the data set in digital form.

Why is verification through a website not enough?

The ministry provides a website to transfer and display customer data. So why do banks need a dedicated solution that follows the above scenario?

First – security. A customer must have no doubts about what data is pulled from the application and to whom it is shared.

In the case of the mWeryfikator application, a customer provides their data to an unknown person (whose identity is not verified or logged in any way) using a publicly available solution.

In a bank that uses the Eximee mObywatel Component, before confirming the transfer of data, a customer: 

  • sees the details of the bank that will receive their identity information,
  • knows exactly what set of data is transferred,

and all operations performed by an employee are logged and subject to audit.

Second – convenience. Customer data is immediately available in integrated banking systems and can be processed without having to rewrite it from a document.

Challenges for banks related to mObywatel


Customer data can be used by unauthorized persons who have access to the system.


The Eximee mObywatel Component can be embedded in the bank’s systems (in this case, Eximee Dashboard), which can only be accessed by authorized employees with specific roles.


Employees may abuse collecting customer identity data.


Every action taken by employees, along with details about the customer data they’ve acquired and the context in which it was obtained, is meticulously recorded in the audit log. It provides a basis for analyzing employee operations and enables the detection of non-standard activity.


The data read from mDowód may not be consistent with the data stored in the bank’s customer registry.


The component integrates with banking systems and verifies the received data with the bank’s customer registry

It allows employees (or the system!) to instantly compare data from different documents and detect any inconsistencies or the need for updates.


During a single visit to a bank branch, an employee may have to enter customer data several times.


Often, a customer wants to handle several matters in one visit to the branch, and each matter requires authorization or data retrieval.

In order for customers not to have to perform the mDowód authorization procedure several times, we have equipped Eximee mObywatel Component with a customer identity cache that stores data during the logged-in employee’s session. Data stored in a cache can be retrieved by various banking systems.

Examples of current implementations

The core process flow of the authentication process is unified (it stems from the ministry’s guidelines). However, individual implementations differ in: 

  • scope (some banks already have components that only need to be tweaked or extended; in other banks, they have yet to be implemented),
  • additional features that augment the core process, such as cache, integration with the existing processes, or bank customer registry.

Bank A: implementation of the entire service

In the first example, the bank used the Eximee GUI component and Eximee API, which includes an audit log and customer identity cache. In this scenario, the bank does not prepare any elements on its own. All they need to do is obtain the BackSystem application from the ministry, which Eximee integrates with.

Bank B: implementation of the Eximee mObywatel Component

The bank already has a customer identification system (equivalent to Eximee mObywatel API). It decided to extend it to support mDowód. Eximee provides the mObywatel Component, consisting of: 

  • front-end component,
  • and a “backend-for-frontend" (i.e., a small backend for the front-end needs) responsible for communication between the banking API and Eximee’s front-end component.

The Eximee mObywatel Component can be embedded in different systems (e.g., any branch system), so the bank does not need to create a separate mObywatel verification service for each.


Your bank can leverage our ready-made mDowód solutions and expand them with additional functions, as needed. If you’re interested in what we can achieve together, schedule a meeting and let’s talk: 


  • Eximee news


Tomasz Ampuła
Product Owner & Digital Transformation Expert
Helps banks optimize product sales and after-sales service. Specializes in corporate banking and omnichannel.