Use cases

This chapter describes the processes that take place within the IBAN Management Service from the perspective of both the customer and the end user. It also includes information on how to integrate with the solution.

Bank account number prefix

After signing an agreement with a payment institution, an IBAN prefix will be assigned to the instance within a given bank for a given currency. The user can receive an IBAN based on the prefix immediately after creating a balance, via API, or after generating it using the Admin Panel. These options are configurable and defined during the onboarding stage, but can be changed at a later date.

Technical balance

When you create an account in Antaca, a technical balance is also created for you. This is a crucial component of the system, as it holds funds that, for some reason, did not reach their intended destination and must be returned to the sender. The technical balance is created during the setup process of your Antaca instance.

Display bank account number

The user who logs into the Customer application can see their balance and the IBAN assigned to it. This allows them to share the IBAN with a potential payer so that the payer can make a transfer to the user's account. With the IBAN visible, the user can also top up their balance by making a bank transfer from an external account. If the end user initiates an outgoing transfer, the IBAN assigned to the balance from which the funds are drawn will appear as the sender's account number in the recipient's transfer history.

The IBAN can be displayed by using the getIban and getIbanMobile methods, depending on the implementation model used by the Customer. The implementation model also defines the method of Customer authorization in the IMS service. In the case of the Mobile SDK implementation model, the Customer authenticates using a session token received from Mobile DC. In the case of the REST API implementation model, the Customer authenticates through signed x509 certificate.

(On the prototype, the view of the balance and account number in the white label application)

Important! Mobile SDK implementation model is work in progress...

Transfer

Funds can be transferred in many ways. One of the most popular is a transfer using the recipient's account number. In the context of the IBAN Management Service solution, the transfer can be made in two directions.

The first is to receive funds on the account number provided to the entity ordering the transfer - this is an incoming transfer. The receiving domain is responsible for this type of transfer.

The second direction is to send funds to the indicated account number belonging to the recipient - this is an outgoing transfer.  The sending domain is responsible for this type of transfer.

(On the prototype, the view of transfer in the white label application)

Receiving

This functionality allows the end user to receive transfers. The end user using your application is able to share their IBAN with a potential payer. This type of transfer is a transaction that tops up the end user's balance. Since receiving an incoming transfer only requires providing the IBAN to the potential payer, the public part of this domain contains only the balance owner's bank account number.

Sending

This functionality allows both the Customer as a corporation and the end user to order outgoing transfers. An outgoing transfer is a transaction that charges the balance associated with the specified IBAN. The sender must provide the recipient's IBAN for the transfer to be initiated. Depending on the recipient's IBAN, the transfer will be made using the appropriate transfer type — internal, domestic, SEPA, or SWIFT. The types of transfers and their conditions are described here. 

Order transfer in Corporate Panel

As a corporate client, you can also order transfers from the Corporate Panel. The list of tabs includes one labeled “New Transfer.” When you click on it, a transfer form will appear for you to fill out. When ordering a transfer from this section, you must enter the account numbers in the appropriate fields — the account from which the transfer will be made (this account will be debited) and the account to which the amount will be transferred (this account will be credited). Additional required information includes the amount and currency of the transfer, the transfer title, and the recipient's details. After entering the basic information, some fields (e.g., BIC, recipient's address) may be required depending on the type of transfer. Once all the data is entered, you will be able to select the type of transfer and confirm it.

Tip: Here you can find more detailed information about the login process and other use cases available in the Corporate Panel.

(On the prototype, the transfer order view in the Corporate Panel.)

Authorization

For security reasons, a transfer order requires authentication of the ordering entity. Depending on the type of integration you are performing, authentication can be done in different ways.

In the case of server to server integration, we only authenticate the instance of a given Customer as the corporation ordering the transfer in the context of a given user. End user authentication in this case is your responsibility.

There is also a case in which you, as a corporation, want to order a transfer directly from your master balance. In this case, we authenticate you using a pre-signed x509 certificate.

For mobile integration, our mobile SDK will provide authentication via biometrics or end-user PIN. This type of end-user authentication takes place when logging in and making a transfer.

Important! Mobile SDK implementation model is work in progress...

Transaction result

After making each transfer, it is important to have information about it's status. For this reason, we provide the ability to get information about the result of each transaction made. 

Notification to the Customer

Notifications are sent via the Transaction History Core. You can find technical documentation for the service here. Notifications are sent as events that should be handled by the Customer. The Customer should create a POST-type endpoint to allow us to deliver such events.

Each transaction event contains a transaction identifier. Using this identifier, the Customer can retrieve the details of the corresponding transaction using the appropriate method. It is also possible to retrieve a list of all transactions. Implementation details are available in the technical documentation of the Transaction History Core service.

@startuml
skinparam ParticipantPadding 30
skinparam BoxPadding 30
skinparam noteFontColor #FFFFFF
skinparam noteBackgroundColor #1C1E3F
skinparam noteBorderColor #1C1E3F
skinparam noteBorderThickness 1
skinparam sequence {
ArrowColor #1C1E3F
ArrowFontColor #1C1E3F
ActorBorderColor #1C1E3F
ActorBackgroundColor #FFFFFF
ActorFontStyle bold
ParticipantBorderColor #1C1E3F
ParticipantBackgroundColor #1C1E3F
ParticipantFontColor #FFFFFF
ParticipantFontStyle bold
LifeLineBackgroundColor #1C1E3F
LifeLineBorderColor #1C1E3F
}
participant "IBAN Management" as ims
participant "Transaction History Core" as THC
participant "Customer's Server" as issuer
ims->THC: Report performed transfer
THC->issuer: Send notification event on the Customer endpoint
issuer->THC: Get transaction details by received transaction id
issuer<--THC: Return transaction details
@enduml

Note: This is an optional feature, but we recommend using it.

Notification to the user

Important! Implementation work in progress...

Admin Panel

One of the additional functionalities offered by Verestro is the use of an administration panel, which allows the customer to track the transfer history of users, as well as the details of individual transfers, view the IBANs generated per user, and generate IBANs. 

The features available in the Admin Panel as part of the IBAN MANAGEMENT SERVICE are available here. The availability of functionality depends on your role.