# Administration Panel
Administration Panel enables various customer service and reporting actions. It is a central point to get information about user, his or her payment transactions, project performance etc.
# Article
You can find more knowledge about products on this site.
# Customer service and user claims in card issuing
Once you start issuing cards for your users, you will experience a wide range of various problems and requests coming from your customers. In this article we will summarize the most common issues, so that you can get prepared.
These include:
1. Transactions not working
2. Problems with delivery or activation of plastic cards
3. Transaction reversals and refund issues
4. Fraudster activity
**Point 1 - Transactions not working**
The most common problem after starting card issuing is connected with performance of transactions. Your users will inform you about problems with transaction authorisations or merchants not accepting their card etc. There can be plenty of reasons for such problems. The most important are:
- User related issues - especially "insufficient funds". The user tries to pay and he/she does not have enough money on account, but forgets to check. More or less 10% of transactions will fail because of this issue. You need to be ready to inform the user that he/she needs to check his/her balance on account first. Another problem may be connected with users wrongly performing transactions, entering a wrong PIN, etc. In this case you will be able to check in the card issuing system that the transaction failed because of this reason.
- Merchant related issues - 2nd most common cause of the problem. Depending on geography or country, merchants and acquirers may decide to decline a transaction for various random reasons. Typically, it is less than 2% of all transactions. There is very little we can do about it. Sometimes you can contact the acquirer, merchant or local Mastercard to check reasons and discuss how to increase acceptance and it is worth doing in many cases. But in reality this may be difficult to change. In this case you will not be able to check in the card issuing system if the transaction failed. You need to inform the user that we do not see this transaction and he/she needs to contact the merchant or acquirer.
- System related issues - 3rd reason of transaction failures is connected with unavailability of the merchant, terminal, acquirer, Mastercard or card issuer systems. In such a case, most often, you will not be able to see this transaction in our system. You need to inform the user that we do not see this transaction and he/she needs to contact the merchant or acquirer.
**Point 2 - Problems with delivery or activation of plastic cards**
Usually, when you decide to use not only virtual, but also plastic cards, you will experience various problems with personalization, delivery or activation of plastic. In different countries there may be various issues with these processes. They are usually connected with logistics or lack of easy activation methods for cards. Some of those issues can be cleaned by us during the project, but for many of them we will not have a good solution. Actually, in today's digital world, we do not recommend issuing plastic cards, but if you need to do so, get ready for such problems.
**Point 3- Transaction reversals and refund issues**
White paying with cards, customers will experience situations that they want to resign from a transaction after some time. Sometimes immediately - and in this case reversals will be used. Sometimes after several days - in this case refund will be used. In such situations we should receive an authorization from the merchant or acquirer that credits the transaction. We should be able to deliver this message to you, so that you can increase the user's balance on account. But sometimes this process does not work correctly. If the card issuer does not receive a message from the acquirer or payment scheme, we are unable to give you this information. User's funds may get frozen for 2-4 weeks. It is important that you understand that such things happen.
**Point 4 - Fraudster activity**
Any new payment activity in the world is attracting the attention of fraudsters or payment mafias. There are people in the world specialised in stealing card data or making transactions with cards while having no money on accounts. This is a very serious risk for you, as they will be testing your systems as well. This is especially visible if you have many "Do not honour" transactions or weak Know Your Customer processes. Be ready for it. Monitor your traffic. Cards will not always work for all payment transactions, some fraud rules will block suspicious activities, but your online monitoring is necessary.
Those are key points to remember about. Please do not forget about them while launching your card issuing program with us.
Thanks for reading.
# Intro slides
[](https://developer.verestro.com/uploads/images/gallery/2022-05/adminpanel-wiktor-kowalczyk-1-2.jpg)
[](https://developer.verestro.com/uploads/images/gallery/2022-05/adminpanel-wiktor-kowalczyk-1-3.jpg)
[](https://developer.verestro.com/uploads/images/gallery/2022-05/adminpanel-wiktor-kowalczyk-1-4.jpg)
[](https://developer.verestro.com/uploads/images/gallery/2022-05/adminpanel-wiktor-kowalczyk-1-5.jpg)
[](https://developer.verestro.com/uploads/images/gallery/2023-02/image-1677077313344-pptx.png)
[](https://developer.verestro.com/uploads/images/gallery/2022-05/adminpanel-wiktor-kowalczyk-1-7.jpg)
# Overview
The Administration Panel is the essential tool for our Partners to work with your Verestro services. The main purpose of Admin Portal is to provide a web-based environment with the ability to manage customer service actions. The presented solution is prepared for customisation with Partner's brand.
This document is divided into sections that describe the various components of the system. Each section contains a screen presenting the functionality and a detailed description of the states occurring in it.
The mechanisms described in this documentation are the most important ones for all web-based products that rely on Admin Portal. Some functionalities of Verestro have specific screens and processes that are not described here. Administration Panel is going through on-going development and changes to improve its performance so there may be differences in this description and real panel.
### Purpose and scope
This product guide provides a high-level overview of Admin Panel Management. This document covers the following topics:
- description of the all aggregates of operators, including detailed information and possible actions,
- description of possible configurations,
- granting access,
- description of main processes as: login, reset password,
- additional and optional functionalities.
| **Name**
| **Description** |
| Operator
| User using the Portal regardless of role or level of rights.
|
| Session token
| Access to the system by a web application user is secured using a session token to uniquely associate the session with the user. It is required to perform any action.
|
## Access and configuration
### Access solutions
The access to Admin Portal in available in 3 ways:
- direct traffic through VPN (Virtual Private Network) - requires VPN reconfiguration on both sides,
- block access to the domain and allow access from a particular IP address (specific IP addresses or a range
of addresses) - configuration required on Verestro side,
- free access for everyone, who have an account in Admin Portal (no matter if VPN configuration or IP
address are set.
| **Action** | **Description** | **Accessibility time**
|
| Reset password
| Validity of link to reset password.
| 60 minutes
|
| Create an account
| Validity of link to first login to Admin Panel.
| 60 minutes
|
| Login to the panel
| Validity of code (4 numbers) to login.
| 10 minutes
|
| User session
| Session after successful login to the panel.
| 15 minutes
|
| User lock
| Time of lock due to incorrect password.
| max 24h (until midnight next day)
|
| Registration link
| Validity of invitation link.
| 60 minutes
|
These are the default values, they can be changed at the request of the customer.
## Security
The systems offered by Verestro are fully secure, which is confirmed by current third-party certificates. As we store card and payment data we are obliged to comply with strict legal requirements. Card and user data are stored in a specially designed environment - Data Core. This environment is PCI DSS certified. The PCI-DSS standard guarantees the security of payment card data. It ensures that sensitive information is properly guarded and provides maximum security in the payment process. The portal operators' passwords are kept in a different database from the end users' data for security reasons. To encrypt them the algorithm Bcrypt with a cost of 10 is used. The cost parameter specifies a key expansion iteration count as a power of two, which is an input to the crypt algorithm.
We achieve high security standards by, among other things :
1. Building and maintaining network security - the need to build and maintain a firewall configuration that protects cardholder data, not using manufacturers' default passwords and settings.
2. Protecting cardholder data - protecting stored cardholder data, encrypting data transmissions when using public networks.
3. Maintaining a payment management program - using regularly updated anti-virus systems, developing secure systems and applications.
4. Implementing strong access control methods - limiting access to cardholder data to only those with a business need, assigning each user a unique ID, limiting physical access to cardholder data.
5. Regular network monitoring and testing - testing security systems and processes, controlling access to network resources and cardholder data.
6. Maintaining information security policies - relying on security policies for employees and vendors.
| **Aggregate area**
| **Action**
| **Admin**
| **Manager**
| **Employee**
|
| Portal management - Operators | View | x | x | - |
| Create | x | x | - |
| Edit | x | x | - |
| Delete | x | x | - |
| Lock | x | x | - |
| Unlock | x | x | - |
- An operator with the `admin` label:
- Can view, create, edit, and delete other operators, regardless of their assigned labels.
- Has full visibility of all users, including other `admin`, `manager`, and `employee` operators.
- May assign any access label to other operators.
- Has access to access label management (assign to operator).
- An operator with the `manager` label:
- Can manage operators labeled as `employee` only.
- Has access to operator management functions (view, create, edit, delete) within this scope.
- Cannot view or modify users with `manager` or `admin` labels.
- An operator with the `employee` label:
- Does not have access to operator management functionalities.
- Can only perform tasks allowed within their assigned label scope, as defined per product configuration.
### Operators list
Administration Panel Accounts list contains filters and columns with dates. In this section detailed lists don’t occur. The filters are used for dynamic searching, such data as: e-mail, first name, last name, group (available: admin, manager, employee).
[](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1656331005778.png)
Basic list includes following information:
| **Parameter**
| **Description**
|
| Group
| Group determines the access level.
|
| E-mail
| Admin e-mail address.
|
| First name
| Admin first name.
|
| Last name
| Admin last name.
|
| Status
| Admin status (described in admin statuses part).
|
| Actions
| Action which can be performed on particular admin (described in admin actions part).
|
### Account statuses
Referring to the above tables, the possible transition of operator states is presented in the diagram below.
Standard flow - operator is created in status invited (Admin Panel MDES/VCP scenario).
[](https://developer.verestro.com/uploads/images/gallery/2022-05/image-1651747168588.png)
Alternative flow - operator is created in status inactive.
[](https://developer.verestro.com/uploads/images/gallery/2022-05/image-1651747318434.png)
### Accounts actions
Administration Panel user can perform the following actions for the particular user (admin, manager, employee):
a) add admin/manager/employee – necessary to input following data: group (select: admin, manager, employee), first name, last name, e-mail. In order to confirm “Save” button should be clicked. Added user should receive e-mail with link to activate account and set the password.
[](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1656331146694.png)
b) edit admin/manager/employee – possible to change following data: group (select: admin, manager, employee), first name, last name, e-mail. There's no option to edit operator with status "invited", in this particular case it's necessary to delete invitation and add a new operator.
[](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1656331033302.png)
c) lock admin/manager/employee – temporary lock of user.
[](https://developer.verestro.com/uploads/images/gallery/2022-06/image-1656331068038.png)
## Notifications in the system
This section contains all email messages that are sent in the system to the portal operator.
Emails from Admin Panel to operator.
| **Process**
| **Topic**
| **Details**
| **Comment**
|
| Invitation to the system
| Set password to administration panel.
| Hello!
You are receiving this e-mail because an account was created for you, and you need to set a new password.
<button to set password>
Regards,
< NameOfClient >
| Standard email sent when portal operator added new operator.
|
| Login process
| Login code.
| Hello!
Your login code: <code>
Regards,
< NameOfClient >
| Standard AP email sent when portal operator entered correct email and password.
|
| Reset password
| Reset password to administration panel.
| Hello!
You are receiving this mail because someone initialized password reset for your account. If it was not you, you can ignore this mail.
<button to reset password>
Regards,
<NameOfClient>
| Standard Admin Panel email sent when portal operator uses "reset password" button on login page.
|
| Additional password policy
| Password expiration reminder.
| Hello!
Your password will expire in <NumerOfDays> days. Please change your password to avoid losing access to the portal.
Regards,
<NameOfClient>
| Related to additional policy to force password changes.
|
| Inactive account policy
| Inactive account reminder.
| Hello!
Due to inactivity your account will be blocked in <NumerOfDays> days. Please log into the portal to avoid losing access to the portal.
Regards,
<NameOfClient>
| Related to the additional policy of automatically deactivating unused accounts.
|
## Additional features
This section focuses on additional functionality in the system. By default they are disabled, they can be enabled upon request during panel creation or panel version upgrade.
### Token blacklisting
For better security, a mechanism for blacklisting session tokens has been prepared. This makes it possible to prevent unauthorized access to the portal and data using the session token of a logged out user (if the token life has not expired yet).
It should be noted that during the logout process the session token in the user's browser is destroyed, regardless of whether the blacklisting mechanism is enabled. Also, closing the browser deletes the token.
However, a theoretical scenario is that the user's token is intercepted and used for unauthorized access to the system. Access possible for the lifetime of the token.
When this mechanism is enabled, the token is blacklisted (and therefore prevented from further use despite the active life time) and each query to the backend (API Admin Panel) checks whether the token used by the user is not blacklisted.
### Session extension popup
Sometimes the session time may not be sufficient to perform the portal user's operations. For this reason a mechanism has been created to ask the user if there is a need to extend the current session.
It should be noted that by default when half of the session time elapses and the user performs some action (moves to another tab, clicks a button) the session time is renewed. By session time renewal it is meant that a new session token is assigned to the user and the session time counter is restored to its default, maximum value.
When the mechanism is active at a certain time before the end of the session the user is asked if he needs more time (screen below). If user chooses affirmative answer, there is assigned a new session token and the session time is restored to the default, maximum. Selecting no closes the dialog. Not selecting an option will close the dialog when the session time expires and the user is logged out.
[](https://developer.verestro.com/uploads/images/gallery/2022-05/image-1651747543966.png)
### Tooltip for table row values
Depending on the resolution and screen size, the appearance of each screen may vary cosmetically. Admin Panel is responsive but values in tables can be of different length (up to 255 characters). It is not always possible to display the entire value in a single table cell. For this reason, a mechanism was created to display a tooltip for table cell values.
The default mechanism is to show the user as many characters as fit into the table cell - depending on the screen size of the device. It is possible in this case to copy the whole, valid value of the cell. Unfortunately it is not possible to preview it by user in simple way - it is necessary to copy cell value e.g. to text document to know its characters that do not fit in the cell.
By enabling described mechanism the tooltip is displayed when the user hovers the mouse over a particular value in the table and waits for 1 second without moving the mouse. The user can easily see the entire value of such a variable.
[](https://developer.verestro.com/uploads/images/gallery/2022-05/image-1651747568528.png)
### Password policies
As it is extremely important for us to ensure the security of the portal operators' data and the data to which the operators have direct access, we are providing an additional policies for passwords.
#### User lock
For added security, a popular mechanism has been implemented to lock the user's account for the period set in the configuration options. By default, the operator's account is blocked until the end of the day after 3 incorrect login attempts, i.e. if the user enters the wrong password 3 times, he will not log in. Such a user can be unblocked, for example, by correctly performing a password reset.
#### Force password change
The first of the additional policies that can be used on the admin instance of the panel is to force the operators to change the password every specified number of days. In the case of inactivity on the part of the operator the account is locked - its unlocking is possible through a password reset mechanism. Before the account is blocked, an email notification is sent about the need to change the password - the time when the email is to be sent is configurable.
#### Force unique password
A second, additional safeguard in password security policies is to prevent a user from setting a password that they have already used in the past. With this mechanism, it is possible to configure how many previous passwords should be excluded from reuse. Of course, for data security reasons, previously used passwords are not stored but only their unique hash, which is used for uniqueness comparison.
#### Deactivate inactive accounts
In order to ensure the safety of the data contained on the portal, an automatic deactivation mechanism for unused accounts has been created. It allows to define the time without logging in after which the operator will be blocked. Unblocking the account is possible by using the password reset mechanism, which is tantamount to confirming your identity and access to your e-mail address.
### Handling an unavailable service
As Admin Panel consists of multiple services (as a reminder, individual services are responsible for the corresponding sections in the side menu), it is important to ensure the availability of the application when any of the individual components is not working (for example, due to a scheduled maintenance outage). For this reason, a mechanism for graying out unavailable services in the side menu has been implemented and enabled by default. If any product/service is temporarily unavailable, the portal operator can still use the functionality provided by the other services. In the case that the unavailable service becomes operational, the section becomes available again after refreshing the page.
# Token Management Administration Panel Overview
The TMP Administration Panel (or the admin portal/portal for short) is the essential tool for you to work with your online application. Here you can manage payment tokens and track history of payments. The presented solution is prepared for rebranding for the client's brand. The document is divided into sections that describe the various components of the system. Each section contains a screen presenting the functionality and a detailed description of the states occurring in it.
### Purpose and scope
This product guide provides a high-level overview of Admin Panel Management. This document covers the following topics:
- description of the all aggregates of tokens, including detailed information and possible actions,
- description of possible configurations,
- granting access,
- additional and optional functionalities.
| **Name**
| **Description** |
| MDES | Mastercard Digital Enablement Services
|
| VTS | Visa Token Service
|
| TMP | Token Management Platform
|
| OTP | One Time Password
|
### Terminology
This section explains a number of key terms and concepts used in this document.
| **Name**
| **Description** |
| Customer | Cardholder.
|
| Operator
| User using the Admin Panel.
|
| Token
| Payment Token.
|
| Session token
| Access to the system by a web application user is secured using a session token to uniquely associate the session with the user. It is required to perform any action.
|
## MAIN VIEW
Once the authentication process is properly completed, the bank employee has access to the panel. It is shown the main screen of the system. Depending on the assigned rights group its appearance may vary. Different roles in the system have different tabs available.
[](https://developer.verestro.com/uploads/images/gallery/2023-04/tmp.png)
The components that make up the Admin Portal are:
1) Main menu contains aggregates as: tokens, history of payments, reports in Token Management Tab and Portal Management Tab.
2) Admin Panel adjusted to the client’s colours and logotype.
3) Filters allows to select multiple filter options and display results that contain information limited all the selected criteria.
4) List of the most important information referring to each aggregate (example: tokens).
5) Actions allows admin to change the status of a single entity or edit data.
## TOKEN MANAGEMENT
### Tokens
Tokens section contains a list of tokens and the filters. The filters are used for dynamic searching, such data as: phone number, VPAN (external card id), path, status last four digits of card or token, payment scheme and others.
[](https://developer.verestro.com/uploads/images/gallery/2023-04/image-1680696691950.png)
#### Basic list includes following information:
| **Parameter**
| **Description**
|
| VPAN
| External Card ID provided by the Issuer.
|
| Payment scheme
| Payment scheme - Mastercard of Visa.
|
| Token
| Token last 4 digits.
|
| Phone Number
| Cardholder's Phone number.
|
| User name
| Cardholder's User name.
|
| Status
| Token status.
|
| Token requestor
| Token Requestor/Wallet.
|
| Device
| Device form factor.
|
| Path
| Inital authorization path - green/yellow/orange/red.
|
| Action
| action which can be performed on particular customer (described in customer actions part).
|
#### Available actions
| **Action** | **Description** |
| Activate | This action activates the token. Available if the token can be activated and is currently INACTIVE. |
| Suspend | This action suspends the token. Available only for ACTIVE tokens. |
| Unsuspend | This action unsuspends the token. Available only for SUSPENDED tokens. |
| Deactivate | This action deactivates the token. Available for all INACTIVE, ACTIVE and SUSPENDED tokens. |
#### Generate tokens report
This button in the top right corner allows generating a report with tokens with applied filters. Maximal date range for a single report is 31 days. The excel file will be generated and automatically downloaded. This report can also be downloaded in Reports section later.
#### Token Details
Selecting a specific token allows to see more detailed data. In addition to basic information.
[](https://developer.verestro.com/uploads/images/gallery/2023-04/image-1680702708968.png)
A list of related status changes, transactions and activation methods used is available.
[](https://developer.verestro.com/uploads/images/gallery/2023-04/image-1680702796336.png)
Detailed list includes following information:
| **Parameter**
| **Description**
|
| Token ID
| Internal Verestro Id of the token.
|
Token unique reference | MDES/VTS token unique reference.
|
VPAN | External Card Id - Issuer Card Id.
|
Status | Token Status.
|
| Status of the tokenization process - IN\_PROGRESS, FINISHED.
|
| Number of sms messages with OTP code sent.
|
| The type of the token: CLOUD/EMBEDDED\_SE.
|
| Wallet ID of the token requestor.
|
| Value linking pre-digitization messages generated during provisioning.
|
| Reason of the last token update.
|
| Identifier of the Payment App instance within a device. NOTE - This may contain the identifier of the Secure Element or a mobile device for some wallets.
|
| Final tokenization decision returned to MDES/VTS.
|
| Reason of the DECLINE, if the tokenization is declined because of invalid card data, exp date or cvc.
|
| Reason of the DECLINE, if the tokenization is declined because of Verestro velocity controls triggered.
|
| Account source - Manual entry, card on file, from mobile application.
|
### Payment history
#### Payment history list
Payment history list contains filters and columns with dates. In this section actions don’t occur. The filters are used for dynamic searching, such data as: phone number, VAPN, date range, status and token requestor . The date is displayed in local time.
[](https://developer.verestro.com/uploads/images/gallery/2023-04/image-1680703618690.png)
Basic list includes following information:
| **Parameter**
| **Description**
|
| Phone number
| Cardholder's phone number (if provided by the Token Requestor).
|
| VPAN
| External Card ID.
|
| User name
| Cardholder's username (if provided by the Token Requestor).
|
| Date
| Transaction date.
|
| Status
| Status of the transaction.
|
| Amount
| Amount.
|
| Currency
| 3-character ISO 4217 currency code of the transaction.
|
| Token requestor | Token requestor . |
#### Generate transactions report
This button in the top right corner allows generating a report with transactions with applied filters. Maximal date range for a single report is 31 days. The excel file will be generated and automatically downloaded. This report can also be downloaded in Reports section later.
#### Payment history details
[](https://developer.verestro.com/uploads/images/gallery/2023-04/image-1680703887183.png)
### Reports
Reports section contains reports that can be downloaded. Each report is valid for a specific duration and can be "Ready" to download or "In progress", which means that a report is still generating.
#### Tokens
This tab contains Tokens reports, generated from Tokens section.
#### Transactions
This tab contains Transactions reports, generated from Transactions section.
#### Apple Pay
This tab contains Apple Pay reports, which are generated automatically each month.
#### Activity
This tab contains Activity reports, which are generated daily. Activity report contain the information about all actions performed on Tokens by Admin Panel users.
[](https://developer.verestro.com/uploads/images/gallery/2023-04/image-1680704065666.png)
## [OPERATOR ADMINISTRATION](https://developer.verestro.com/books/administration-panel/page/overview#bkmrk-%C2%A014-%C2%A0-%C2%A0panel-adminis)
### Default privileges per role in the portal
Below are the default function settings for described product divided into areas.
| **Aggregate**
| **Action**
| **Admin**
| **Manager**
| **Employee**
|
| Token Management - Tokens | View | x | x | x |
| Deactivate | x | x | x |
| Suspend | x | x | x |
| Unsuspend | x | x | x |
| Token Management - Payment history | View | x | x | x |
| Token Management - Reports | View | x | x | - |
| Generate | x | x | - |
| Token Management - Rules | View | x | x | x |
# Overview of Administration Panel main sections
The Administration Panel (or the admin panel/portal for short) is the essential tool for you to work with your online application. Here you can manage customers, their cards, IBANs, devices and track history of payments. The presented solution is prepared for rebranding for the client's brand. The document is divided into sections that describe the various components of the system. Each section contains a screen presenting the functionality and a detailed description of the states occurring in it.
### Purpose and scope
This product guide provides a high-level overview of Admin Panel Management. This document covers the following topics:
- description of the all aggregates of customer, including detailed information and possible actions,
- description of possible configurations,
- granting access,
- description of main processes as: login, reset password,
- additional and optional functionalities.
| **Name**
| **Description** |
| VPN | Virtual Private Network
|
| MPA | Mobile Payment Application
|
| IBAN | International Bank Account Number
|
| MCBP | Mastercard Cloud Base Payment
|
| MDES | Mastercard Digital Enablement Services
|
| LCAPI | Lifecycle API
|
### Terminology
This section explains a number of key terms and concepts used in this document.
| **Name**
| **Description** |
| Customer | Customer who uses MPA.
|
| User
| User using the Admin Panel.
|
| Card
| Section contains information about customer PANs – physical cards added by customer manually in MPA or bank using LC API.
|
| IBAN
| Customer bank account number. MCBP enables bank account numbers to be digitized and used for payments.
|
| Token
| Payment Token in context of MCBP. Tokens are result of correct digitization. Each token has one wallet account, one card/IBAN number and one device related.
|
| Device
| Device is data aggregate related to customer. Device is entity in MDES – created during MDES registration. Each registration of customer has device on Verestro side, but each customer may have multiple MDES registrations.
|
| Payment history
| It’s possible that transaction history will be stored on Verestro wallet server for infinite time (this setting can be specified during onboarding with Mastercard). If these options are enabled, MPA can retrieve transaction history for given user and payment instrument ID. Transactions are returned in corresponding parts for better user experience. Particular transaction may appear on the list with delay – depending on integrated external components.
|
| LCAPI
| API Used for direct integration to partner. Allows to manage users, cards, etc.
|
| Session token
| Access to the system by a web application user is secured using a session token to uniquely associate the session with the user. It is required to perform any action.
|
## Main view
Once the authentication process is properly completed, the bank employee has access to the panel. He is shown the main screen of the system. Depending on the assigned rights group its appearance may vary. Different roles in the system have different tabs available.
[](https://developer.verestro.com/uploads/images/gallery/2025-04/zo1obraz.png)
The components that make up the Admin Portal are:
1) Main menu contains aggregates as: customers, transactions, KYC, Token Management, Finance, Portal management (administrators, visuals, logs). Each section is related to different product from Verestro's portfolio.
2) Admin Panel adjusted to the client’s colours and logotype.
3) Filters allows to select multiple filter options and display results that contain information all the selected criteria.
4) List of the most important information referring to each aggregate (example: customers).
5) Actions allows admin to change the status of aggregate or edit data.
## Customers management
### Customers list
Customer list contains filters and columns with dates. The filters are used for dynamic searching, such data as: customer ID, external ID, e-mail, phone number, status (unverified, verified, locked, deleted).
[](https://developer.verestro.com/uploads/images/gallery/2025-04/qOpscr-20250416-olcb.png)
Basic list includes following information:
| **Parameter**
| **Description**
|
| Customer ID
| Internal Verestro Id of customer.
|
| External ID
| External customer identifier provided by client (for example: recordID).
|
| E-mail
| Customer e-mail address.
|
| Phone number
| Customer phone number with country prefix.
|
| First name
| Customer first name.
|
| Last name
| Customer last name.
|
| Status
| Customer status (described in customer statuses part).
|
| Action
| Action which can be performed on particular customer (described in customer actions part).
|
### Customers details
Selecting a specific user allows to see more detailed data. In addition to personal information, a list of related devices, IBANs, tokens, and payment history is available.
[](https://developer.verestro.com/uploads/images/gallery/2025-04/x53obraz.png)
Detailed list includes following information:
| **Parameter**
| **Description**
|
| Customer ID
| Internal Verestro Id of customer.
|
| External ID
| External customer identifier provided by client (for example: record ID).
|
| First name
| Customer first name.
|
| Last name
| Customer last name.
|
| Phone number
| Customer phone number with country prefix.
|
| E-mail
| Customer e-mail address.
|
| Status
| Customer status.
|
| Number of failed logins
| Number of login failures.
|
| Created at
| Date of customer registration.
|
| Deleted at
| Date of customer deletion (parameter displayed only if customer has been removed from system).
|
Additionally, in details are available lists of aggregates related to the particular customer:
• customer devices (more information in devices management),
• customer IBANs (more information in IBANs management),
• customer cards (more information in cards management),
• customer tokens (related to MDES/VTS payment tokens),
• payment history (more information in payment history).
### Customer statuses
A user can be defined by one of four statuses. The system created by Verestro divides the statuses into the following:
[](https://developer.verestro.com/uploads/images/gallery/2022-05/image-1651662842347.png)
### Customer actions
Admin can perform the following actions on the particular customer:
a) edit customer – redirect to the screen with edition (screen below). The following data can be edited:
• first name,
• last name,
• phone number,
• e-mail,
[](https://developer.verestro.com/uploads/images/gallery/2025-04/zCrobraz.png)
b) lock/unlock customer – temporary lock of customer (more information in customer statuses part),
b) delete customer – permanent delete customer data (more information in customer statuses part).
The following table shows the states of the user's token after performing each action.
| **Action**
| **Token status**
|
| **Add customer**
| Unverified
|
| **User authentication**
| Verified
|
| Lock customer
| Locked
|
| Unlock customer
| Verified
|
| Delete customer
| Deleted
|
Referring to the above table, a diagram has been created showing the change of states of the user token. This allows for better visualization of actions and dependencies between them.
[](https://developer.verestro.com/uploads/images/gallery/2023-03/2023-03-09-14h48-28.png)
## Cards management
### Cards list
Cards list contains filters and columns with dates. The filters are used for dynamic searching, such data as: card ID, last 4 digits, date of creation, status (available: unverified, verified, locked, deleted).
[](https://developer.verestro.com/uploads/images/gallery/2025-04/WEEobraz.png)
Basic list includes following information:
| **Parameter**
| **Description**
|
| Card ID
| Internal Verestro Id of card.
|
| Customer ID
| Internal Verestro Id of customer.
|
| Last 4 digits
| Last four digits of physical PAN.
|
| Exp date
| Expiration date in MM/YY format.
|
| Type
| Card type (Mastercard, Visa).
|
| Status
| Card status (described in card statuses part).
|
| Action
| Action which can be performed on particular card (described in card actions part).
|
### Card details
Selecting a specific card allows to see more detailed data. In addition to basic information, a list of related customers, and payment history is available.
[](https://developer.verestro.com/uploads/images/gallery/2025-04/gsYobraz.png)
Detailed list includes following information:
| **Parameter**
| **Description**
|
| Card ID
| Internal Verestro Id of card.
|
| Last 4 digits
| Last four digits of physical PAN.
|
| Expire date
| Expiration date in MM/YY format.
|
| Description
| Friendly name of card.
|
| Type
| Card type (Mastercard, Visa).
|
| Status
| Card status. Available: verified, unverified, deleted, locked.
|
| Created at
| Date of card addition to the wallet database.
|
| Deleted at
| Date of card deletion from the wallet database.
|
Additionally, in details are available aggregates related to the particular card:
• customers (more information in customers management),
• customer tokens (more information in tokens management),
• payment history (more information in payment history).
### Card statuses
A customer can be defined by one of four statuses. The system created by Verestro divides the statuses into the following:
[](https://developer.verestro.com/uploads/images/gallery/2022-05/image-1651664590912.png)
### Card actions
Admin can perform the following actions on the particular card:
a) view card – redirect to the screen with card details data,
b) lock card – temporary lock of card (more information in card statuses part)
c) delete card – permanent delete card data (more information in card statuses part).
Below table presents how action may change the statuses of card
| **Action**
| **Statuses**
|
|
| **Card’s status**
| **Token’s status**
|
| **Add card**
| Unverified
| |
| **Verify card**
| Verified
| |
| Lock card
| Locked
| Suspended
|
| Unlock card
| Verified
| Active
|
| Delete card
| Deleted
| Deleted
|
Referring to the above table, a diagram has been created showing the change of states of the card. This allows for better visualization of actions and dependencies between them.
If project has enabled Issuer wallet, each action on card - like lock, delete - will initiate process of suspend or deleting related MDES/VTS tokens (transacion credentials) with logic described in Issuer Wallet use cases.
## Devices management
### Devices details
Selecting a specific device allows to see more detailed data. In addition to basic information, a list of related customers, and payment history is available.
[](https://developer.verestro.com/uploads/images/gallery/2025-04/Jg0obraz.png)
Detailed includes following information:
| **Parameter**
| **Description**
|
| Device ID installation
| Unique identifier of app installed on device.
|
| Producer
| Description of phone device manufacturer.
|
| Device name
| Description of phone device model.
|
| Device version
| Version of operating system.
|
| Created at
| Creation date greater than specified date or equal. Format Y-M-D.
|
| Deleted at
| Deletion date greater than specified date or equal. Format Y-M-D.
|
| Status
| Device status.
|
In details there are available aggregates related to the particular device:
• customers (more information in customers management),
• customer tokens (more information in tokens management),
• payment history (more information in payment history).
### Device statuses
### Device actions
Admin can perform the following actions on the particular device:
a) view device – redirect to the screen with device details data,
b) lock device – lock of device. None actions on this device are possible
c) delete device – permanent delete device data.
Below table presents how action may change the statuses of device
| **Action**
| **Statuses**
|
|
| **Device’s status**
| **Token’s status**
|
| **Add device (not paired yet)**
| Inactive
| -
|
| **Pair device**
| Active
| -
|
| Lock device
| Locked
| Suspended
|
| Unlock device
| Active
| Active
|
| Delete device
| Deleted
| Deleted
|
Referring to the above table, a diagram has been created showing the change of states of the device token. This allows for better visualization of actions and dependencies between them.
[](https://developer.verestro.com/uploads/images/gallery/2023-03/2023-03-09-15h17-49.png)
If project has enabled Issuer wallet, each action on card - like lock, delete - will initiate process of suspend or deleting related MDES/VTS tokens (transacion credentials) with logic described in Issuer Wallet use cases.
## Payment history
### Payment history list
Payment history list contains filters and columns with dates. In this section actions don’t occur. The filters are used for dynamic searching, such data as: Card ID, amount, currency, date of transaction, status (available: cleared, declined, authorized, reversed). The date displayed in both the transaction list and details is in UTC+0 and ISO8601 compliant. Also, the filters are selected by the user in UTC+0. At no time is there a conversion to the local time zone of the portal operator.
Basic list includes following information:
| **Parameter**
| **Description**
|
| Transaction ID
| Internal Verestro transaction identifier.
|
| Card ID
| Internal Verestro Id of Card.
|
| Created at
| The date/time when the transaction was made. In ISO 8601 extended format.
|
| Amount
| The transaction monetary amount in terms of the minor units of the currency.
|
| Currency
| 3-character ISO 4217 currency code of the transaction.
|
| Status
| Transaction status (described in transaction statuses part).
|
### Payment history details
Selecting a specific payment history allows to see more detailed data.
[](https://developer.verestro.com/uploads/images/gallery/2022-05/image-1651746768526.png)
Detailed list includes following information:
| **Parameter**
| **Description**
|
| Transaction ID
| Internal Verestro transaction identifier.
|
| Token ID
| Internal Verestro Id of Token.
|
| Card ID
| Internal Verestro Id of Card.
|
| IBAN ID
| Internal Verestro Id of IBAN.
|
| Created at
| The date/time when the transaction was made. In ISO 8601 extended format.
|
| Amount
| The transaction monetary amount in terms of the minor units of the currency..
|
| Currency
| 3-character ISO 4217 currency code of the transaction.
|
| Status
| Transaction status.
|
| Decline reason
| Additional information provided by the issuer for a declined transaction.\*
|
| Customer ID
| Internal Verestro customer identifier.
|
| External ID
| External customer identifier provided by client (for example: recordID).
|
| E-mail
| Customer e-mail address.
|
| Phone number
| Customer phone number.
|
| Transaction channel
| Information about transaction channel. One of: \[CONTACTLESS, CLOUD, MONEYSEND\].
|
| Merchant name
| The merchant ("doing business as") name.
|
| Merchant postal code
| The postal code of the merchant.
|
| Transaction country code
| The country in which the transaction was performed. Expressed as a 3-letter (alpha-3) country code as defined in ISO 3166-1.
|
| Type
| Transaction type.\*\*
|
\*Type of declined transactions:
a) invalid card number,
b) format error,
c) maximum amount exceeded,
d) expired card,
e) PIN authorization failed,
f) tranaction not permitted,
g) exceeds withdrawal amount limit,
h) restricted card,
i) exceeds withdrawal count limit,
j) allowable number of PIN tries exceeded,
k) incorrect pin,
l) duplicate transmission detected.
\*\*Type of transactions:
a) purchase transaction,
b) refund transaction,
c) payment transaction,
d) ATM cash withdrawal,
e) cash disbursement,
f) ATM deposit,
g) ATM account transfer.
### Transaction statuses
Each transaction has a transaction id given by the client, a type and a status. In payment systems, when a transaction is of type REFUND, it has the same id as a transaction of type PURCHASE. Therefore, the unique key is(the id given by the customer and the transaction type). Transaction amounts are stored in the system as a minor(1.25 to 125).
Each transaction has a type that can have different statuses. Immediately after a transaction is executed, it may receive one of the following statuses:
| **Parameter**
| **Description**
|
| AUTHORIZED
| The transaction was authorized correctly. The funds in the Cardholder's account are blocked and an amount of the same value is "promised" to the Merchant. No transfer of funds is performed at this time.
|
| DECLINED
| The transaction was declined. No funds are blocked/transferred from Cardholder's account.
|
For a transaction authorized correctly (AUTHORIZED), the following scenarios are possible. It may go into status:
| **Parameter**
| **Description**
|
| REVERSED
| The transaction is reversed, e.g. due to an error reported by Merchant. The lock is lifted and the funds remain on the Cardholder's account. No transfer of funds is performed.
|
| CLEARED
| The transaction was settled correctly. The funds in the Cardholder's account are unblocked, and are then transferred to the Merchant's account. The block on the Cardholder's account becomes a debit, and the "promised" funds become a credit on the Merchant's account.
|
Referring to the above tables, the possible transition of transaction states is presented in the diagram below.
[](https://developer.verestro.com/uploads/images/gallery/2023-03/2023-03-09-15h30-41.png)
## [Operator administration](https://developer.verestro.com/books/administration-panel/page/overview#bkmrk-%C2%A014-%C2%A0-%C2%A0panel-adminis)
### Default privileges per role in the portal
Below are the default function settings for described product divided into areas.
| **Aggregate**
| **Action**
| **Admin**
| **Manager**
| **Employee**
|
| Customers - Cards | View | x | x | x |
| Delete | x | x | - |
| Block | x | x | - |
| Unblock | x | x | - |
| Customers - Endusers | View | x | x | x |
| Edit | x | x | - |
| Delete | x | x | - |
| Lock | x | x | x |
| Unlock | x | x | x |
| Customers - Devices | View | x | x | x |
| Lock | x | x | x |
| Unlock | x | x | x |
| Delete | x | x | - |
| Customer - Tokens on details of Endusers/Devices/Cards | View | x | x | x |
| Suspend | x | x | x |
| Unsuspend | x | x | x |
| Delete | x | x | - |
| Customers - Payment history | View | x | x | x |
| Customers - Reports | View | x | x | - |
| Generate | x | x | - |
## Reports
### Payment history report
Payment history reports use the same filters that are used to select the payment history list. After applying the appropriate set of filters (Card ID, amount, currency, data range and status) it is possible to generate a report that will include the records displayed in the list.
Clicking the "Generate transactions report" button launches the generation mechanism. If the generation request was successful a popup is displayed at the bottom of the panel informing about the start of work (image below). In case of an error caused by missing data in the specified filter range the message "Cannot find transactions to generate the report" is displayed.
When user opens the "Reports" tab, a list of reports is displayed. It contains ready to download output files (.xlsx) in Ready status and information about reports currently being processed - In\_Progress.
The report file contains the following columns:
| **Column**
| **Description**
|
| Transaction ID
| Internal Verestro transaction identifier.
|
| Payment token ID
| Internal Verestro token identifier.
|
| IBAN ID
| Internal Verestro IBAN identifier.
|
| Card ID
| Internal Verestro Id of Card.
|
| Card last four digits
| Last four digits of card, which has been used to process transaction.
|
| Created at
| The date/time when the transaction was made. In ISO 8601 extended format.
|
| Amount
| The transaction monetary amount in terms of the minor units of the currency.
|
| Currency
| 3-character ISO 4217 currency code of the transaction.
|
| Status
| Transaction status (described in transaction statuses part).
|
| Issuer response information
| Additional information received from Issuer in context of transaction.
|
| Customer ID
| Internal Verestro customer identifier.
|
| Customer external ID
| External system customer identifier.
|
| Customer email
| Customer email address in format alias@domain.
|
| Customer phone number
| Customer mobile phone number with prefix.
|
| Transaction channel
| Type of transaction channel used to perform the transaction.
|
| Merchant name
| The merchant ("doing business as") name.
|
| Transaction country code
| 3-character ISO 3166-1 country code of the transaction.
|
By default, both report generation and report retrieval are unlimited, meaning that any role can use this functionality in an unlimited way. If there are reasons to limit e.g. only Administrator to generate reports and allow everyone to view them - please let us know during project configuration stage.
# Finance Administration Panel Overview
The Finance Administration Panel is the essential tool for you to work with your online application. Here you can manage balances for both corporations and endusers and generate virtual cards also. The presented solution is prepared for rebranding for the client's brand. The document is divided into sections that describe the various components of the system. Each section contains a screen presenting the functionality and a detailed description of the states occurring in it.
### Purpose and scope
This product guide provides a high-level overview of Admin Panel Finance section. This document covers the following topics:
- managing End-user Balance,
- managing Master balances,
- managing Company balances,
- transaction clearing,
- partner accounting,
- AML user lock
- privileges per role.
| **Name**
| **Description**
|
| Customer, Partner
| Customer who uses MPA.
|
| Operator
| User using the Admin Panel.
|
| BIN Sponsor
| Financial institution holding a direct license from card networks (e.g., Visa, Mastercard). The BIN Sponsor provides its Bank Identification Number (BIN) and acts as the formal guarantor responsible for the regulatory and legal compliance of transactions processed by its Client.
|
| Balance
| Representation of funding collection in specific currency.
|
| Session token
| Access to the system by a web application user is secured using a session token to uniquely associate the session with the user. It is required to perform any action.
|
| IBAN
| International Bank Account Number
|
| AML
| Anti-Money Laundering
|
## Customer Balance
Customer balances can be managed from end-user detail view, in "Balances" section. (*Customers tab -> Endusers tab -> Enduser details -> Balances section*).
[](https://developer.verestro.com/uploads/images/gallery/2024-03/end-user-detailed-view-balances-tab.png)
Balance view provides the following key information for each entry:
| **Parameter**
| **Description**
|
| Balance ID
| Unique balance ID.
|
| Currency
| Currency for given balance in ISO 4217 format.
|
| Balance
| Amount of funds available on the balance.
|
| IBAN
| IBAN for the given balance.
By default, it is hidden for security reasons and can be viewed by clicking the 'Reveal' button.
This functionality is available only if IBANs are within the scope of the project.
|
##### Add new balance
Operator can create new balances with **`Add new balance`** button. After clicking it, operator should choose currency for new balance from dropdown list. Newly created balance is visible on Balances list right away.
Balances can be created for any currency. However cards can be created only for currency compliant with end-user balance currency and currency configured in terminal for given project.
##### Balance detail view
Balance detail view can be entered by click on a row in Balance table, described above.
[](https://developer.verestro.com/uploads/images/gallery/2024-03/balance-detail-view-2.png)
The page is divided into four distinct sections:
1. **Details**
Contains: Balance ID, Balance Currency and Current Balance.
2. **List of IBANs**
Contains all IBAN information: IBAN ID, Created date, Currency, IBAN, Status.
3. **List of cards**
Contains all cards assigned to given balance along with informations: Card ID, Activation date, Expiration date, Type and Processor ID.
4. **Statements**
A list of statements generated for the given balance. These statements can be automatically generated and added on a monthly basis.
##### Generate card
This functionality enables the Operator to create a virtual card. Upon clicking **`Generate card`**, a pop-up displays a list of terminals configured for the project.
The Operator must select a terminal with a currency that corresponds to the end-user's balance currency. The newly generated virtual card is verified immediately.
##### Change balance
Operator with Admin role can change end-user balance using **`Change balance`** button.
[](https://developer.verestro.com/uploads/images/gallery/2024-03/change-balance.png)
1. Select Type:
a) Credit - A transaction crediting the balance
b) Debit - A transaction debiting the balance
2. Select Transaction type (described in the table below).
3. Enter Transaction amount.
4. Enter Transaction description.
5. Enter Transaction ID - optional parameter.
6. Click **`Confirm`**.
The balance is updated immediately.
| **Type**
| **Transaction type**
| **Description**
|
| Credit
| Cashback
| Internal transaction for a Partner who wants to top up the user's balance as part of the loyalty program.
Antaca automatically debits the credit Master balance with this transaction.
|
| Loan
| Internal transaction for a Partner who want to top up end user's balance as part of the credit agreement.
Antaca automatically debits the credit Master Balance with this transaction.
|
| Payment
| Internal transaction type used to top up the user's balance. This type indicates that the funds come from the Antaca system, usually in conjunction with a funding type a debit transaction on the user's balance.
Antaca automatically debits the credit Master balance with this transaction.
|
| Top up
| Internal transaction type used to top up end user balance. This type indicates that the funds come from outside the Antaca system, e.g. payment to an account at a bank branch.
Antaca automatically debits the credit Master balance with this transaction.
|
| Debit
| Commission | Internal transaction for a partner who wants to debit user balance as a commission referenced to the other transaction.
|
| Fee | Internal transaction for a partner who wants to debit user balance as a fee.
Antaca automatically credits Company balance with the funds debited from end user balance.
|
| Funding
| Internal transaction type used to debit the user's balance. This type indicates that the funds still remain in the Antaca system, usually in conjunction with a credit type transaction on the user's balance.
Antaca automatically credits the credit Master Balance with this transaction.
|
| Withdrawal
| Internal transaction type used to debit end user balance. This type indicates that the funds go outside of Antaca system, e.g. withdrawal from an account at a bank branch.
|
##### Delete balance
Delete balance option is available only for balances equal to 0.00 and all transactions are cleared. Deleted balance is no longer visible in the End-user's Balances tab. All cards assigned to deleted balance are deleted as well.
Operator with Admin or Manager role can delete end-user balance on balance detail view.
## Master balance
The Master Balance tab allows for the management of the Master Balance account and provides visibility into all transactions that have been executed on that balance.
1. Deposits - includes a list of Master Balances created for Partner with amount of funds and currency.
2. Filters - allow searching for transactions specific for given time frame, type (credit or debit), amount and transaction title.
3. List of transactions - list of transactions generated for selected Master Balance.
List includes following information:
| **Parameter**
| **Description**
|
| Transaction date
| Transaction date in YYYY-MM-DD format and 24 hour format (UTC+0).
|
| Title
| Description of the transaction.
|
| Amount
| Amount of transaction with currency code.
|
| Type
| Type of transaction.
Available values "Debit" and "Credit".
|
##### Change balance
To generate a transaction on the Master Balance, the Operator should perform the following actions:
1. Select proper Master balance.
2\. Select "Change balance" button.
3\. Select transaction type.
4\. Enter transaction amount.
5\. Enter transaction description.
6\. Add transaction ID (optional).
7\. Click "Confirm".
This action results in a change to the Master Balance and the immediate saving of a transaction in the "List of transactions" table. These transactions are recorded instantly with the status `CLEARED`.
Only the BIN Sponsor is authorized to modify the state of the Master Balance.
##### Generate report
Additionally, this screen allows for the generation of a transaction report based on the applied filters.
The report includes the following data fields:
| **Parameter**
| **Description**
|
| ID
| Unique ID of the transaction.
|
| External ID
| An identifier from an external system linked to this transaction.
|
| EventType
| Indicates the type of event that triggered the transaction.
Available values: Credit, Debit.
|
| Type
| Transaction type.
|
| TransactionDate | The date and time when the transaction was initiated.
|
| Amount | The original value of the transaction before any adjustments or reversals (minor value).
|
| AdjustmentAmount | The amount added or subtracted due to a correction or modification of the original transaction.
**This value is typically 0 for Master Balance transactions.**
|
| ReversalAmount | The amount related to the cancellation or partial-reversal a previously posted transaction.
**This value is typically 0 for Master Balance transactions.**
|
| Finalamount | The final amount calculated after considering the original amount, adjustments, and reversals.
|
| Currency | The three-letter ISO 4217 code of the currency used for the transaction amount (e.g., PLN, USD).
|
| Description | Description of the transaction.
|
| Status | The current processing status of the transaction.
This value is typically `CLEARED` for Master Balance transactions.
|
| ReferenceTransactionId | The ID of another transaction related to this transaction.
|
| AccountingBalance | The balance of the company account after this transaction was cleared.
|
| ClearedAt | The date and time when the transaction was finally settled (cleared).
|
| TerminalId | The ID of the card terminal that processed the transaction associated with this record.
|
The maximum time range allowable for generating reports is 3 months.
## Balance statistics
The Balance Statistics page provides crucial information regarding the necessary capital a Partner must maintain in their bank account to ensure money liquidity for their project. It aggregates the totals of end users' balances and the Partner's own balances for a selected currency.
On this screen, you can choose the currency you are interested in. After selection, the page shows the current values for:
| **Parameter**
| **Description**
|
| Total user balance
| The aggregate funds across all end-user balances.
|
| Total company balance
| The total amount held in the company balance.
|
| Total deposit Master balance
| The total amount held in the deposit Master balance.
**Is applicable only if the Partner has the deposit Master Balance enabled.**
|
| Total credit Master balance
| The total amount held in the credit Master balance.
**Is applicable only if the Partner has the credit Master Balance enabled.**
|
| Bank Account
| The sum of the Total User Balance, Total Company Balance, and Total Master Balance.
|
## Manual clearings
The Manual Clearings page displays all transactions registered in Antaca as well as settlements generated within the payment network. The Manual Clearings feature enables the BIN Sponsor to clear transactions that were not processed automatically.
Page is divided into two sections:
##### 1. Transactions
Operator can filter transactions using following filters:
- Date from,
- Date to,
- Terminal,
- Transaction ID,
- Customer ID,
- Card ID,
- Type,
- Status
The main list provides the following information about the transactions:
| **Parameter**
| **Description**
|
| Transaction ID
| An identifier from an external system linked to this transaction.
|
| Description
| Description of the transaction.
|
| Card ID
| The unique, internal numerical identifier assigned to the card (integer).
|
| Type
| Type of transaction.
|
| Final amount
| The final amount calculated after considering the original amount, adjustments, and reversals (gross value).
|
| Transaction date
| Transaction date in YYYY-MM-DD format and 24 hour format (UTC+0). |
| Status
| The current processing status of the transaction.
Available values:
- `Authorized`,
- `Cleared`,
- `Reversed`.
|
Clicking on a transaction record opens a popup window displaying the detailed transaction information:
| **Parameter**
| **Description**
|
| Transaction ID
| Unique ID of the transaction.
|
| Transaction External ID
| An identifier from an external system linked to this transaction.
|
| Amount
| The original value of the transaction before any adjustments or reversals (gross value).
|
| Currency
| The three-letter ISO 4217 code of the currency used for the transaction amount (e.g., PLN, USD).
|
| Adjustment amount
| The amount added or subtracted due to a correction or modification of the original transaction.
|
| Reversal amount
| The amount related to the cancellation or partial-reversal a previously posted transaction.
|
| Related transactions
| A list of transactional events (e.g., authorizations, settlements, reversals, adjustments) that influenced to the final state and amount of the current transaction record. |
##### 2. Settlements
Operator can filter settlements using following filters:
- Date from,
- Date to,
- Terminal,
- Transaction ID,
- Customer ID,
- Card ID,
- Status,
- Processed.
The main list provides the following information about the settlements:
| **Parametr**
| **Description**
|
| Transaction ID
| An identifier from an external system linked to this transaction.
|
| Description
| Transaction description.
|
| Card ID
| The unique, internal numerical identifier assigned to the card (integer).
|
| Amount
| The final, confirmed amount transferred during the clearing process.
|
| Transaction date
| Transaction date in YYYY-MM-DD format and 24 hour format (UTC+0). |
| Processed at
| Settlement clearing date in YYYY-MM-DD format and 24 hour format (UTC+0).
|
Clicking on a settlement record opens a popup window displaying the detailed information:
| **Parameter**
| **Description**
|
| Currency
| The three-letter ISO 4217 code of the currency used for the transaction amount (e.g., PLN, USD).
|
| Type
| describes the transaction type, such as:- DEDUCT
- LOAD
- REVERSAL
|
| Settlement amount
| Settlement amount of the transaction. |
| Transaction narrative
| The merchant’s description.
|
| System date
| Issuer processor's system date.
|
| Sequence number
| Unique sequence card identifier from the Issuer processor. |
| Tracking number
| Unique tracking identifier from the Issuer processor. |
| Interchange amount
| Cost or income generated as a result of settlement previously authorized transactions. |
##### Download settlement
Download settlement option allows for the re-initiation of the settlement file download for a specific day and terminal, in cases where the automatic download failed for any reason.
##### Reverse transaction
It is possible to reverse a transaction that remains in the **AUTHORIZED** status (not CLEARED or REVERSED).
1. Select the relevant transaction on the list.
2. Choose the **"Clear transaction"** option.
3. Enter the amount to be reversed.
Possible results:
- Partial Reversal - If the amount entered is lower than the authorized transaction amount, a partial reversal should be generated.
- Full Reversal - If the amount entered is equal to the authorized transaction amount, the entire transaction is reversed, and its status changes to `REVERSED`.
- Error - If the amount entered is higher than the authorized transaction amount, an error should be returned indicating this discrepancy.
##### Clear transactions
To clear transactions, the Operator should perform the following actions:
1. Select one or more transactions to be cleared.
2. Select the settlement to be linked with the transactions chosen in step 1 (this step is optional).
3. Click the **Clear transactions** button at the top right of the page.
Following this process:
- - The status of the selected transactions is changed to `CLEARED`.
- The settlement chosen in step 2 (if selected) will have its **`Processed at` **parameter set to the date of the clearing action.
- The corresponding`INTERCHANGE` transaction will be generated.
Manual clearings tab is only available to the BIN Sponsor.
## Partner accounting
The Partner Accounting page was designed to present information regarding the Partner's profit for a given project. It contains a list of transactions, such as fees, interchange, FX conversion and transactions generated manually by the BIN Sponsor.
The page is divided into 3 sections:
1. Company balance - list of Partner balances with balanceId and specific currency.
2. Filters - allow searching for transactions specific for given time frame and type of transaction (credit or debit).
3. List of transactions
| **Parametr**
| **Description**
|
| Transaction date
| Transaction date in YYYY-MM-DD format and 24 hour format (UTC+0).
|
| Title
| Transaction description.
|
| Amount
| Transaction gross value with currency.
|
| Type
| Transaction type.
Available values: Credit, Debit.
|
| Subtype | Detailed transaction classification
Examples:
- **INTERCHANGE** - This transaction is generated as a result of the settlement of authorized transactions.
- **FOREX** - A transaction specifically related to foreign currency exchange or conversion.
- **FEE** - A transaction that charges the customer and credits the company's balance. It is related to a charge for a specific service or account management.
- **COMPANY - **internal transaction dedicated only for bin-sponsor to debit/credit company balance used for settlements between the partner and the bin-sponsor.
|
| Terminal ID | The ID of the card terminal that processed the transaction associated with this record.
|
##### Generate a transaction
To generate a transaction and modify the Company balance, the Operator should perform the following actions:
1. Select proper company balance.
2. Select 'Generate a transaction' button.
3. Select transaction type.
4. Enter transaction amount.
5. Enter transaction description.
6. Add transaction ID (optional).
7. Click 'Confirm'.
2. The transaction will be processed with a subType of `COMPANY`.
The 'Generate a transaction' action can only be performed by the **BIN Sponsor.**
##### Generate a report
Additionally, this screen allows for the generation of a transaction report based on the applied filters.
The report includes the following data fields:
| **Parameter**
| **Description**
|
| ID
| Unique ID of the transaction.
|
| External ID
| An identifier from an external system linked to this transaction.
|
| EventType
| Indicates the type of event that triggered the transaction.
Available values: Credit, Debit.
|
| Type
| Transaction type.
|
| TransactionDate | The date and time when the transaction was initiated.
|
| Amount | The original value of the transaction before any adjustments or reversals (minor value).
|
| AdjustmentAmount | The amount added or subtracted due to a correction or modification of the original transaction.
**This value is typically 0 for Company Balance transactions.**
|
| ReversalAmount | The amount related to the cancellation or partial-reversal a previously posted transaction.
**This value is typically 0 for Company Balance transactions.**
|
| Finalamount | The final amount calculated after considering the original amount, adjustments, and reversals.
|
| Currency | The three-letter ISO 4217 code of the currency used for the transaction amount (e.g., PLN, USD).
|
| Description | Description of the transaction.
|
| Status | The current processing status of the transaction.
This value is typically `CLEARED` for Company Balance transactions.
|
| ReferenceTransactionId | The ID of another transaction related to this transaction.
|
| AccountingBalance | The balance of the company account after this transaction was cleared.
|
| ClearedAt | The date and time when the transaction was finally settled (cleared).
|
| TerminalId | The ID of the card terminal that processed the transaction associated with this record.
|
The maximum time range allowable for generating reports is 3 months.
Operator with any role can use 'Generate report' functionality.
## AML User lock
The AML User Lock enables an Operator with any role to lock a resource that does not comply with AML (Anti-Money Laundering) regulations. This functionality results in the transactional blockade of the resource. Any transaction being processed for the locked resource will be automatically rejected with the reason code: `FRAUD_SUSPECTED`.
The page is divided into two main sections:
1. **Filters** – Allows browsing locked resources by their type (e.g., Customer), ID, and Lock reason.
2. **List of locked resources** – Displays the resulting list of locked entries.
| **Parameter**
| **Description**
|
| Blocked resource
| Shows blocked resource type.
Available values:
CUSTOMER
CORPORATION
|
| Resource ID
| Verestro ID for given resource.
|
| Reason
| Available values:
DOCUMENT EXPIRED
FRAUD SUSPECTED
SCREENING DETECTED
TEMPORARY LOCKED
PEKAO LOCK
ZEN LOCK
PROSECUTOR LOCK
FENIGE LOCK
POLICE LOCK
MANY CARDS LOCK
NAGATIVE VERIFICATION
PRADO VERIFICATION
|
| Action
| Available actions:
- Remove the lock.
|
#####
Add new lock
To create a new lock, use the "New lock" button in the top right corner of the page. Clicking this button opens a popup window:
[](https://developer.verestro.com/uploads/images/gallery/2024-05/aml-user-lock-new-lock.png)
Once the Blocked resource, Resource ID, and Reason for lock are entered, the newly added lock becomes visible in the list of locked resources.
##### Remove the lock
To remove the lock, the Operator should click on the 'Action' menu within the lock list and select the "Remove the lock" option.
[](https://developer.verestro.com/uploads/images/gallery/2024-05/aml-lock-remove-the-lock.png)
The lock will be instantly removed from the list.
The 'Remove the lock' option is available only to Operators with the Admin role.
##### Automatic Lock Triggers
In addition to manual creation by an Operator, locks may also be imposed by automated processes. These automated locks typically occur based on predefined system rules or risk assessments. Automated processes that can result in a lock being placed are:
- Document Expired - Applied when the documents required for the KYC (Know Your Customer) process have expired.
- Screening Detected - Applied when a customer screening reveals a match on a sanctions list.
## Default privileges per role in the portal
Below are the default function settings for described product divided into areas.
| **Area**
| **Action**
| **Admin**
| **Manager**
| **Employee**
|
| Customer Balance
| View Company Balance
| x | x | - |
| Create Customer Balance | x | x | - |
| View Customer Balance | x | x | x |
| View Customer Balance Details | x | x | x |
| Topup Customer Balance | x | - | - |
| Delete Customer Balance | x | x | - |
| Customer
| Delete Customer | x | x | - |
| Master Balances
| View Master Balance
| x
| x
| -
|
| Edit Master Balance
| x
| -
| -
|
| KYC
| View KYC applications
| x
| x
| -
|
|
| Update KYC applications
| x
| x
| -
|
| Cards
| Create virtual card
| x
| x
| x
|
|
| View cards
| x
| x
| -
|
|
| Delete cards
| x
| x
| -
|
|
| Create Card Limit | x | x | x |
|
| View Card Limits | x | x | x |
|
| Update Card Limits | x | x | x |
|
| Delete Card Limits | x | x | x |
|
| Generate CVV | x | x | x |
| Clearing | Manual clearing | x | - | - |
|
| Manual reversal | x | - | - |
| Partner accounting | View Company Balance
| x | x | - |
|
| Edit Company Balance
| x | - | - |
|
| Report generating
| x | x | x |
| AML User Lock | List of locks | x | - | - |
|
| Add new lock | x | - | - |
|
| Remove the lock | x | - | - |
# IBAN Management Administration Panel Overview
The IBAN Management Service module provides a centralized interface for managing bank accounts and transfers. As a Payment Institution, you are granted extended administrative capabilities, allowing you to manage the full lifecycle of banking products and maintain regulatory compliance.
The document is divided into sections that describe the various components of the system. Each section contains a screen presenting the functionality and a detailed description of the states occurring in it.
You can find more about the IBAN Management Service product [here](https://developer.verestro.com/books/iban-management).
### Purpose & scope
This product guide provides a high-level overview of Admin Panel IBAN Management section.
| **Name**
| **Description**
|
| **Transaction & bank account monitoring
** | Provides continuous visibility into all bank accounts and transfers. You can track transaction history, verify account and transfer statuses and details. |
| **Account generation**
| It provides the ability to generate a bank account assigned to a specific balance. |
| **AML Decision Management**
| It allows payment institutions to exercise direct control over compliance processes. You can manage and execute AML-related decisions for both incoming and outgoing transfers, including reviewing and approving or rejecting transactions based on established rules and your risk assessment. |
### Terminology
This section explains a number of key terms and concepts used in this document.
| **Name**
| **Description**
|
| **Partner
** | An institution using Verestro products. Essentially, a Partner can be referred to as a Verestro client.
|
| **Operator**
| User using the Panel regardless of role or level of rights.
|
| **AML Operator**
| User using the Administration Panel which actions are connected with Anti-Money Laundering area.
Issuing Institution representative.
|
| **Upload**
| The process of transferring (importing) the bulk transfer data files to the banking system.
|
| **Master balance** | The total funds in Master Account. Master Account is the main account number assigned to the Partner in the bank's system |
| **Technical balance** | A balance that takes into account funds pending finalisation, such as held transfers for AML reasons. |
## Transaction & bank account monitoring
### Transfers
| The `Transfers` tab provides comprehensive visibility into **all transactions** executed within your implementation. You can efficiently navigate the transaction history using an extensive set of filters, including:
`Transfer ID`, `Created at`, `Sender's account number`, `Receiver's account number`, `Bank`, `Direction`, `Account Type`.
Each entry provides access to all essential transfer data. By selecting a specific transaction, you can access:
- Transfer history- a chronological log of the transaction's lifecycle.
- Related transfers & refunds- immediate visibility into associated movements.
- Upload details- applies to external outgoing transfers and their execution within the upload.
For enhanced transparency and streamlined investigation, the details view **allows for direct navigation to the associated user profile or related transfers**, ensuring all necessary information is just one click away.
| [](https://developer.verestro.com/uploads/images/gallery/2026-02/image.png) |
[](https://developer.verestro.com/uploads/images/gallery/2026-02/transfers-list.png)
The list view allows you to access the **details of any transfer**. It includes the specific transfer history and its connections to others. Furthermore, you can navigate to the tab of a user holding an Antaca balance by clicking on their ID.
[](https://developer.verestro.com/uploads/images/gallery/2026-02/transfer-details.png)
| **Name**
| **Description**
|
| **Transfer history
** | The history of changes made during transfer execution, including the `date`, `owner`, and the `name `of the change. |
| **Related transfers**
| All transfers associated with the main transaction, e.g., moving funds to the technical balance when a transfer is held. |
| **Refunds**
| Refunds made within a given transfer, e.g. after rejection by the department or AML rules. |
| **Upload details**
| Applies to transfers sent to the bank for execution via bank upload. This doesn't apply to internal transfers (within the same implementation) or incoming transfers. |
### Bank accounts
| The `Accounts` tab enables you to track any bank account generated as part of your implementation.
You can check the bank `account number`, `currency`, the assigned `bank`, the `owner `(corporation or user), the `owner ID` (which redirects you to their tab when clicked), as well as the account `status `and `creation date`.
Just like in the Transfers tab, you can **filter the results.** The available filters are: `Account number`, `Currency`, `Bank`, `User ID`, `Corporation ID`, `Balance ID`, `Created at`, and `Status`.
You can view all accounts in the Accounts tab, but generation is handled via the specific customer profile, found [here](https://developer.verestro.com/books/administration-panel/page/iban-management-administration-panel-overview#:~:text=account%2Dgeneration%2D1-,Account%20generation,-Generate%20bank%20account).
| [](https://developer.verestro.com/uploads/images/gallery/2026-02/image.png) |
[](https://developer.verestro.com/uploads/images/gallery/2026-02/accounts.png)
After entering the details of a specific account, both the information from the list and also the `Bank BIC` and `Balance `are visible- with redirection to the tab of this balance.
## Account generation
### Generate bank account
| **Depending on your business model and configuration, your customers may consist of endusers or corporations.**
To generate an account for a customer, follow these steps:
1. Find them on the list- you can use dedicated filters for convenience:
1. In the Endusers tab: `Enduser ID`, `External ID`, `Email`, `Phone numbe`r, `Status`, `First name`, `Last name`.
2. In the Corporations tab: `Corporation ID`, `Corporation name`, `Representative first name`, `Representative last name`, `KYB status`.
2. Go to the customer’s balances.
3. Generate an account assigned to the balance.
If an account has already been generated for a given balance, this section allows you to view or delete it.
You can find more information about bank accounts and their generation flow [here](https://developer.verestro.com/books/iban-management/page/use-cases#:~:text=iban%2Dtransfer%2Dreceiv-,Account%20Management,-You%20have%20the).
| [](https://developer.verestro.com/uploads/images/gallery/2026-02/lKiimage.png)
|
## AML Decision Management
### Transfers for review
| This section contains transfers separated from the main pool (found in the `Transfers `tab) that **require a decision from an AML operator for further processing**. Due to AML rules, their execution has been suspended pending verification.
The list view displays the following transfer parameters: `amount`, `user ID`, `created at`, `direction`, `reason for review`, and `actions`. **Available actions depend on the "reason for review" and may include issuing a refund, accepting the transfer, or rejecting it.**
Records in the Transfers for Review tab can be filtered using the following parameters: `Transfer ID`, `Amount`, `Currency`, `Account number`, `User ID`, `Corporation ID`, `Direction`, `Created at`, `Account type`, `Bank`, and `Reason for review`.
Access to the functionalities in this section is limited to the **AML team**.
| [](https://developer.verestro.com/uploads/images/gallery/2026-02/image.png) |
| A held transfer can be either `accepted` or `rejected` by the AML operator.
These **actions are available** from both the **list view** and the **details view**. The details view is identical to the one in the Transfers tab.
**The outcome of rejecting a transfer depends on its direction:**
- upon rejecting an incoming transfer, a manual refund can be initiated;
- rejecting an outgoing transfer triggers an automatic refund.
| [](https://developer.verestro.com/uploads/images/gallery/2026-02/LYhimage.png)
|
| [](https://developer.verestro.com/uploads/images/gallery/2026-02/OjIrefund.png)
| If the transfer is rejected, the AML operator from Payment Institution defines further reprocessing of the transfer. Depending on the case, the transfer may return to the original sender or change the intended recipient.
After rejecting a transfer, the AML operator has the option to initiate a refund of the given transfer. This will be visible in the transfer history module, as well as in the `related transfers` and `refunds` section. Multiple refund transfers can be made in relation to a single transaction.
**The sum of the amounts of refund transfers cannot exceed the amount of the original transfer.**
Manual refunds are available once an incoming transfer is rejected.
Since a held transfer results in funds being posted to a technical balance, both approval and refunding require a transfer of funds from the technical balance, which will be reflected in the transfer history.
|
## Roles and labels
Below are the default function settings for described product. In addition to roles, there are also labels for actions in the IBAN Management area, which extend the role's permissions. The roles of `ADMIN`, `MANAGER`, `EMPLOYEE` overlap with the `ADMIN`, `MANAGER`, `EMPLOYEE` labels.
| **Roles**
| **Labels**
|
| Admin
| Admin
|
| Manager
| Manager
|
| Employee
| Employee
|
|
| Transfer\_maker |
|
| AML |
| **Action**
| **Admin**
| **Manager**
| **Employee**
| **Transfer\_maker**
| **Aml**
|
| Views | X | X | X |
|
|
| Display bank account number details
| X | X | X |
| X |
| Display bank accounts list | X | X | X |
| X |
| Reveal bank account | X | X | X |
| X |
| Display main accounts | X |
|
|
|
|
| Create bank account | X |
| |
| X |
| Assign main bank account | X |
| |
|
|
| Delete bank account | X |
|
|
| X |
| Display transfers
| X | X | X |
|
|
| Display transfers details | X | X | X |
|
|
| Make transfer (create, cancel, calculate options)
| X |
| | X |
|
| Accept transfer | X |
| | | X |
| Reject transfer | X | | | | X |
| Display refunds | X | X | X |
|
|
| Display transfers for review | X | X | X |
|
|
| Display transfer history | X | X | X |
|
|
| Display related transfers | X | X | X |
|
|
| Display transfer bank upload | X | X | X |
|
|
# KYC Panel Overview
The KYC Administration Panel is the essential tool for you to work with your online application. Here you can manage Know Your Customer applications. The presented solution is prepared for rebranding for the client's brand. The document is divided into sections that describe the various components of the system. Each section contains a screen presenting the functionality and a detailed description of the states occurring in it.
### Terminology
This section explains a number of key terms and concepts used in this document.
| **Name**
| **Description**
|
| Customer, Partner
| Customer who uses MPA.
|
| Operator
| User using the Admin Panel.
|
| Balance
| Representation of funding collection in specific currency.
|
| Session token
| Access to the system by a web application user is secured using a session token to uniquely associate the session with the user. It is required to perform any action.
|
## KYC
KYC (Know Your Customer) page enables Operator with Admin role to manage end users' verification applications. Customer application page consists of:
1. Filters section - application can be filtered by Customer ID, date of creation and status.
2. Lists of applications
| **Parametr**
| **Description**
|
| ID
| KYC application ID.
|
| Customer ID
| End user ID given by Verestro.
|
| First name
| End user first name.
|
| Last name
| End user last name. |
| Status
| KYC application status. Available values: In progress, Accepted, Rejected.
|
After clicking on a row of the list, Operator is navigated to KYC application detailed view.
[](https://developer.verestro.com/uploads/images/gallery/2024-03/kyc-detail-view.png)
In Details section all informations provided by end user are presented. Some of the data can be edited regardless of KYC application status \[?\]. Pencil icon indicates editable data.
Below Details section Operator can find documents attached to KYC application. Files can be added by end user during KYC process or by Operator with "Drag and drop" functionality available below files list. Admin Panel support following file formats: pdf, jpeg, png and jpg. Each file size is limited to 2 MB.
At the right bottom corner of the page Operator with Admin role can see 3 buttons to change KYC apllication status:
1\. Success - changes KYC application status to "Accepted"
2\. Fail - changes KYC application status to "Rejected". End user has to create new KYC application.
3\. Block - changes KYC application status to "Rejected". End user cannot create another KYC application.
[](https://developer.verestro.com/uploads/images/gallery/2024-05/kyc-action-buttons.png)
When changing KYC status to "Success" Operator has to select Risk Level for given end user, selecting one of folloing values: Low, Medium, High.
# AML Transaction Monitoring - Administration Panel Overview
The AML Transaction Monitoring GUI enables operators to configure custom rulesets, define value sets and actions for transaction monitoring, and manage user watchlists. The system is currently being enhanced with a testing feature for dry‑run ruleset validation and an analytics dashboard for monitoring AML transaction patterns and statistics.
### Purpose & scope
This documentation covers the primary processes within the AML configuration module of the partnerbank Admin Panel.
| **Name** | **Description** |
| Ruleset management | Creating and managing rule configurations for transaction monitoring. |
| Actions management | Defining actions returned by the AML system. |
| Value set management | Managing internal variables and stored values. |
| Watchlist management | Adding and removing users from blacklists and greylists. |
### Terminology
| **Name** | **Description** |
| End user | Cardholder performing transactions. |
| Operator | User working with the Administration Panel. |
| Ruleset | Predefined sets of conditions checked and processed after receiving a transaction verification request. |
| Action | Response returned by the AML system that must be processed by the external product sending the verification request. |
| Value set | Internal variable storing multiple values (for example: UHRC country codes in ISO Alpha‑2 format). |
| Watchlist | Internal storage for suspicious users, checked during transaction verification to determine appropriate decisions and actions. |
## RULESETS TAB
This section of the GUI is responsible for managing rulesets, value sets and actions.
### Rulesets
#### Defining a ruleset
To create a new ruleset, follow these steps. On the right you can insert a screenshot of the Add ruleset page to illustrate the process.
| 1. Navigate to **AML → Rules** and ensure the **Rule sets** tab is active.
2. Click the **Add ruleset** button.
3. Enter a descriptive **Name** for your ruleset (this field is required).
4. Provide the full rule logic in the **Ruleset definition** text area (in YAML format).
5. (Optional) Toggle **Enable test ruleset** to run the ruleset on historical transactions without affecting live processing.
6. Decide whether to save the ruleset as disabled or enabled by clicking **Save as disabled** or **Save as enabled**. Use **Cancel** to abort.
| [](https://developer.verestro.com/uploads/images/gallery/2025-11/cZYimage.png)
[](https://developer.verestro.com/uploads/images/gallery/2025-11/9Qsimage.png)
|
**Note:** A traditional YAML builder using forms and blocks is under development. In the final version, rulesets can be defined either with the text editor or with an easy-to-use form.
#### Ruleset list
You can view all configured rulesets in the **Rule sets** tab. The list displays:
| **Column** | **Description** |
| ID (uuid) | Unique internal identifier of the ruleset. |
| NAME | Descriptive name of the ruleset. |
| CREATED\_AT | Date and time when the ruleset was created. |
| UPDATED\_AT | Date and time when the ruleset was last modified. |
| ACTIVE | Indicates whether the ruleset is enabled (blue switch) or disabled (grey switch). |
| ACTION | Menu containing actions such as view details, edit or delete. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/4JRimage.png)
#### Ruleset details
When you click a ruleset row, a detailed view opens showing all configuration fields. The table below summarises these elements.
| **Element** | **Description** |
| Basic data | The panel that summarises the ruleset’s *ID (uuid)*, *Name*, *Created\_at* and *Updated\_at* values. |
| ID (uuid) | Unique identifier of the ruleset, displayed in the Basic data panel. |
| Name | The descriptive name of the ruleset, shown in the Basic data panel. |
| Created\_at | The date and time when the ruleset was created. |
| Updated\_at | The date and time when the ruleset was last modified. |
| Ruleset definition tab | The tab that displays the YAML definition of the ruleset, including conditions, triggers, decisions and actions. |
| Ruleset tests tab | The tab used for running and viewing test results for the ruleset. |
| Edit button | A button that opens the ruleset edit form. |
| Test ruleset button | A button that runs a dry‑run test on the ruleset using historical transaction data. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/P7bimage.png)
#### Ruleset activation / deactivation
When creating a ruleset, the operator chooses whether the ruleset should be active right away or saved in a disabled state by selecting **Save as enabled** or **Save as disabled**. Once the ruleset exists, its state can be toggled on or off at any time from the list view: use the status switch to enable or disable the ruleset and confirm the change. Changes take effect immediately after confirmation.
| **Status indicator** | **Description** |
| Blue switch | The ruleset is enabled. The toggle switch is coloured blue and positioned to the right. |
| Grey switch | The ruleset is disabled. The toggle switch is grey and positioned to the left. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/gj9image.png)
#### Ruleset testing (dry‑run)
**Note:** Feature under development. The dry‑run engine will allow operators to run rulesets against historical transaction data and view the result that the ruleset would return without impacting live processing.
### Value sets
#### Defining a value set
Follow these steps to create a new value set. Use the right column for a screenshot of the “Add value set” page.
| 1. Navigate to **AML → Rules** and open the **Value sets** tab.
2. Click the **Add value set** button.
3. Provide a descriptive **Name** in the *Name\** field (this is required).
4. In the *Value set* area, enter each value. Existing values are displayed as tags with an **x** to remove them. Use the **add value +** button to add additional entries.
5. Click **Save** to create the value set or **Cancel** to discard your changes.
| [](https://developer.verestro.com/uploads/images/gallery/2025-11/kV8image.png)
[](https://developer.verestro.com/uploads/images/gallery/2025-11/screenshot-2025-11-30-at-14-17-26.png)
|
#### Value sets list
The **Value sets** tab lists all defined value sets. Each row includes the following columns:
| **Column** | **Description** |
| ID (uuid) | Unique identifier of the value set. |
| NAME | The name of the value set. |
| ACTION | Menu containing available operations such as view details, edit or delete. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/kT7image.png)
#### Value set details
Selecting a value set opens a detailed view where you can add or remove individual values. The elements are described below:
| **Element** | **Description** |
| Basic data | A panel summarising the value set’s *ID (uuid)* and *Name*. |
| ID (uuid) | Unique identifier of the value set. |
| Name | The name of the value set. |
| Value set | The list of values stored in the set. Each value appears as a tag with an option to remove it; new values can be added using an input or the **add value +** button. |
| Edit button | A button in the top‑right corner that opens the value set edit form. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/FZcimage.png)
### Actions
#### Defining an action
The table below outlines the steps for creating a new action. A screenshot of the “Add action” page can be placed in the right column.
| 1. Navigate to **AML → Rules** and open the **Actions** tab.
2. Click the **Add action** button.
3. Enter the action name in the *Name\** field (required).
4. Select a *Group\** from the dropdown list (required).
5. Define one or more properties for the action:
- Provide a **Property name\***.
- Choose whether the property is required by selecting **No** or **Yes**.
- Enter allowed values as tags in the **Value** field and use the **add value +** button to add additional values.
6. If additional properties are needed, click **Add new property** and repeat the previous step.
7. Click **Save** to create the action or **Cancel** to discard your changes.
| [](https://developer.verestro.com/uploads/images/gallery/2025-11/kQuimage.png)
[](https://developer.verestro.com/uploads/images/gallery/2025-11/4Xdimage.png)
|
#### Action list
The **Actions** tab lists all configured actions. Each row shows:
| **Column** | **Description** |
| ID (uuid) | Unique identifier of the action. |
| NAME | The name of the action. |
| GROUP | The group to which the action belongs. |
| ACTION | Menu containing available operations such as view details, edit or delete. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/086image.png)
#### Action details
Clicking an action opens a details page that displays its configuration. The table below describes each element.
| **Element** | **Description** |
| Basic data | A panel summarising the action’s *ID (uuid)*, *Name* and *Group*. |
| ID (uuid) | Unique identifier of the action. |
| Name | The name of the action. |
| Group | The group to which the action belongs. |
| Property | Details for each property defined in the action. Each property contains a name, a required flag and a list of values. |
| Property name | The name of the property (e.g. *resource\_type*). |
| Required | Indicates whether the property is mandatory (true) or optional (false). |
| Values | The allowed values for the property, shown as tags (e.g. `FRAUD_SUSPECTED`, `DOCUMENT_EXPIRED`). |
| Edit button | A button that opens the action edit form. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/i6dimage.png)
## WATCHLISTS
The system supports two watchlist types: **Blacklist** and **Greylist**. Both lists are managed identically; you can switch between them using the tabs at the top of the watchlist management page.
### Blacklist
#### Adding a user
| 1. Navigate to **AML → Watchlists**.
2. Select the **Blacklist** tab.
3. Click the **Add user** button.
4. Fill in the user information fields, including **Name**, **Surname**, **Full name**, **Birth date**, **Pesel**, **Document number**, **Document type**, **Country**, **City** and **IBAN** (if applicable).
5. Click **Save** to add the user.
| [](https://developer.verestro.com/uploads/images/gallery/2025-11/kQhimage.png)
[](https://developer.verestro.com/uploads/images/gallery/2025-11/wPyimage.png)
|
**User information fields:**
| **Field** | **Description** |
| Name | User’s first name (required). |
| Surname | User’s surname (required). |
| Full name | The person’s full name (first and last names together). |
| Birth date | Date of birth (required). |
| Pesel | Personal identification number (PESEL) (required). |
| Document number | Identification document number (required). |
| Document type | Select from dropdown (Passport, ID card, etc.). |
| Country | Select country from dropdown. |
| City | Enter city name. |
| IBAN | Bank account number (if applicable). |
**Important:** Adding a user to a watchlist does not automatically trigger any actions. A ruleset must reference the watchlist to determine whether to approve, decline or place a transaction on hold.
#### Removing a user
| 1. Navigate to **Watchlists → Blacklist**.
2. Use the search filters to locate the user.
3. Click the actions menu (three dots) for that user.
4. Select **Delete** and confirm the removal.
| [](https://developer.verestro.com/uploads/images/gallery/2025-11/pcrimage.png)
|
#### Searching and filtering
The watchlist management page includes filters to narrow down the list of users:
| **Filter** | **Description** |
| Name | Filter by name (first name). |
| Surname | Filter by surname. |
| Full name | Filter by full name (first and last names together). |
| Pesel | Filter by personal identification number (PESEL). |
| Document number | Filter by identification document number. |
| Country | Filter by country (dropdown). |
| City | Filter by city. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/breimage.png)
#### Blacklist table
The blacklist displays the following columns for each entry:
| **Column** | **Description** |
| ID | Internal identifier for the entry (UUID shown truncated). |
| NAME | First name of the user. |
| SURNAME | Surname of the user. |
| BIRTH DATE | Birth date of the user. |
| PESEL | Personal identification number (PESEL for Polish users). |
| DOCUMENT TYPE | Type of identification document. |
| COUNTRY | Country. |
| ACTIONS | Menu for managing the entry (delete). |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/CO1image.png)
#### Blacklist record details
To view detailed information about a specific entry on the blacklist, click on the row in the table. An expanded section will appear below the row showing additional details about the user:
| **Field** | **Description** |
| Full name | The user’s full name. |
| Document number | The identification document number associated with the user. |
| City | The user’s city. |
| IBAN | The user’s bank account number, if provided. |
[](https://developer.verestro.com/uploads/images/gallery/2025-11/qSVimage.png)
### Greylist
The greylist is functionally identical to the blacklist.
All operations — adding users, removing users, filtering and managing entries — are the same.
Refer to the [**Blacklist**](#bkmrk-blacklist) section above for full instructions.