0% found this document useful (0 votes)
745 views64 pages

Card Issuing Bank Accounts

This document provides a comprehensive overview of card issuing and bank accounts, detailing the processes, key players, and financial aspects involved in card issuing, particularly focusing on Mastercard and VISA. It outlines the roles of cardholders, merchants, issuers, acquirers, and payment schemes, as well as important processes such as card issuing, transaction processing, and compliance requirements. Additionally, it discusses factors to consider when choosing a card issuing partner and the potential revenue streams associated with card issuing.

Uploaded by

myheromom01
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
745 views64 pages

Card Issuing Bank Accounts

This document provides a comprehensive overview of card issuing and bank accounts, detailing the processes, key players, and financial aspects involved in card issuing, particularly focusing on Mastercard and VISA. It outlines the roles of cardholders, merchants, issuers, acquirers, and payment schemes, as well as important processes such as card issuing, transaction processing, and compliance requirements. Additionally, it discusses factors to consider when choosing a card issuing partner and the potential revenue streams associated with card issuing.

Uploaded by

myheromom01
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 64

Card Issuing & Bank

Accounts
How does card issuing work? Check here.

Payment schemes

Ranking of card issuing companies

Card issuing - financial details

Example of Profit & Loss calculation in card issuing

Regulatory and license impact on card issuing

KYC and KYB requirements in card issuing

PCI DSS & other security requirements

Master balance and collateral in card issuing projects

Pay with Rewards, Pay with Points

Multicurrency cards - 3 implementation options

Customer service and user claims in card issuing

How to prepare for a card issuing project?

How can I reload a payment account or card?

Card Lifecycle Management

VISA or Mastercard?

Card Benefits in card issuing projects

Prepaid, debit or credit cards - the main differences

Tips to avoid problems when implementing card issuing

Know Your Customer – in-house or outsourcing

Reverse solicitation – marketing & promotion of card issuing in multiple countries

Interchange Fees and Service Fees - rates and rules

BIN Range or Separate BIN in Card Issuing

Guide to IBAN setup process


IBANs, cards, balances - how to manage all of this?

Issuing cards in various currencies

What steps should be taken to start a card issuing project with Verestro outside the

European Economic Area?


Payment schemes
In this document we describe how payment schemes (Mastercard and VISA) work.

Payment card business is a large global market, which was developed in the USA in the first half of
XX century and has grown globally. In this document we will describe the main business principles
and in the next chapters we will go into more details. We will focus mainly on Mastercard and VISA
operations, as these are the largest payment schemes in the world and the main partners we work
with.

Four Party Model

Let's start with the general relationships between the parties. In the Mastercard and VISA 4-party
model (which is actually 5-party model) there are the following players:

1. Cardholder - has a contract with Card Issuer, which is usually a bank, financial institution,
payment institution, credit union, etc. Cardholder keeps a card in a plastic or virtual form that
he/she gets from Issuer. Cardholder makes a purchase transaction at Merchant or sometimes
withdraws money from an ATM. In the case of an ATM transaction, the ATM operator (usually a
bank) acts as Merchant in a standard purchase transaction.

Cardholder is happy because he/she does not need to carry cash all the time and has
money all the time in their pocket or phone.
Cardholder has to pay card fees to Issuer for getting a payment card.
2. Merchant - delivers goods to Cardholder, but does not receive cash immediately, but accepts
the card transaction, which gives him/her almost 100% confidence that he/she will receive money
in a few hours or days.

Merchant is happy because he/she sold goods, usually having sold more than Cardholder
could afford with cash. Imagine the situation where you have to pay cash all the time.
Would you always carry enough cash with you? What if you want to buy something, but
you do not have enough cash?
Merchant has to pay the so called "Merchant Fees" to Acquirer for processing the
transaction. Usually, Merchant Fees are between 0,5-3% depending on transaction value,
country, merchant segment, type of card etc. Merchant fees cover most, if not all, of the
transaction processing costs. They usually include all the fees charged by Acquirer, Issuer,
Mastercard or VISA for the transaction.

3. Issuer - Issuer is usually a bank, credit union or any other payment institution that delivers
payment cards to cardholders (consumers or businesses). Issuer signs contracts with cardholders.
On the other side of business, Issuer has a franchising or licensing contract with VISA and
Mastercard and connects to their network using Issuing Processors. Verestro and our partners (for
example Quicko) plays the role of Issuer and Issuer Processor in our card issuing or BIN sponsorship
projects. During the transaction process, Issuer usually gets authorization, clearing and settlement
messages that result in transfer of money from a cardholder account to Acquirer so that Acquirer
could settle the transaction with Merchant.

Issuer is happy because they charge card fees to Cardholder (for example monthly per
card) and get transaction fees called Interchange Fee from Acquirer. Interchange fee is a
very important part of Merchant Fees. In the European Union for consumer cards it is
usually in the value of 0,2-0,3%, but in many countries, especially for business and credit
cards, it can amount to 1-2% of the transaction value.
Issuer has to cover costs of card issuing, which include:
Cost of payment scheme (Mastercard or VISA) incl. monthly connection, license,
authorization, clearing and many many other fees. This is usually the main part of
Issuer's costs.
Cost of other processors incl. transaction authorisation, card maintenance, card
tokenization, plastic card manufacturing, personalisation, delivery, etc.
Regulatory costs incl. payment license operations, Anti-Money Laundering processes,
etc.
Various costs connected with maintaining a relationship with Cardholder incl. proper
communications, SLAs, etc.

4. Acquirer - Acquirer is usually a bank or payment institution that signs contracts with
merchants, settles payment transactions with merchants and has acquiring contracts with a
payment scheme. Acquirer usually provides a payment terminal to merchant locations, and makes
sure if it works and is ready for transactions.

Acquirer is happy because they charge Merchant Fees that usually consist of transaction
fees (0,5-3%), sometimes fixed fees per transaction (0,01-0,5 EUR) and monthly fees per
terminal.
Acquirer needs to cover various fees, including regulatory fees, payment scheme costs,
cost of processors, terminal purchase and costs of operations.

5. Payment Scheme - Payment Scheme (i.e. Mastercard or VISA) are key for keeping the model
running. They develop technical systems that issuers and acquirers are connected to, they process
transactions, they develop the market. However, they are also the biggest beneficiaries of the
market growth as every new transaction represents revenue for Mastercard and VISA.

Key Processes
There are several processes that take place during card and transaction processing, and here we
will briefly describe the most important ones:

Card issuing process - this process or set of processes consists of multiple actions that
Card Issuer needs to perform to issue a payment card. They are the following:
regulatory compliance - every card issuer in the world needs to comply with law, get
license from a national bank or financial regulator, work according to their
recommendations and rules,
Mastercard integration and licensing - it consists of a formal process, providing
necessary cash collaterals, doing technical integration, getting security certifications
etc.,
card creation process - after signing a contract by a user, Card Issuer needs to
create a new card number (using BIN of the issuer - BIN = first 6 or 8 digits of card).
When a card number (PAN = Primary Account Number) is created, the card can
immediately work as a virtual card or can be sent for personalisation if it is a plastic
card. Usually, after the user receives the card (virtual or plastic), the user starts the
card activation process, sets the card PIN and can start using it.
Transaction process - this process consists of several operations that result in transfer
of money from Cardholder account to Merchant. They are the following:
Authorization process is an action that ensures that Merchant can immediately get
information if Cardholder has money on his/her card account and if this card is not
stolen. The authorisation can happen online (a direct request to Issuer's system to
check the balance and card status) or offline (in this case a chip on the card makes a
decision if it can approve the transaction without asking Issuer's systems).
Clearing process is an action of payment scheme during which clearing files are
delivered by acquirers to payment scheme and payment scheme calculates how
much money each Acquirer should receive from each Issuer in the world.
Settlement process is a process of transferring money from issuers to acquirers and
later to merchants so that finally Merchant receives the transaction amount, less
Merchant Fees, on his/her bank account. Every Issuer and Acquirer has settlement
bank accounts that are used for transferring money from or to. Payment Schemes
operate those accounts using something like Direct Debit / Credit to transfer money
between Settlement Accounts of various financial institutions.
3DS - sometimes additional authentication mechanisms are used to ensure that the
person initiating the card transaction is the actual cardholder. In the case of
eCommerce transactions this process is called 3DS. During an Internet transaction,
the user's browser opens the bank's website, where the user can authenticate the
transaction using one-time passwords or other forms of authentication developed by
Issuer. After the 3DS authentication is verified, Acquirer receives a special
cryptogram that is included in the authorization message and validated later by
Issuer during the authorization process.
Tokenization - tokenization is a process of exchanging a real card number into a
token number (similar to a card number) to enable digital and contactless payments.
Usually it is connected with transactions performed in cooperation with the so called
X-Pays (i.e. Apple Pay, Google Pay, Fitbit Pay etc.). The process of tokenization
requires an integration with Mastercard Digital Enablement System (MDES) or Visa
Tokenization system (VTS) to enable tokenized payments.
Refund and reversal - special type of transactions that enable reversing payment
transaction either immediately (reversal) or later (refund). Once this process has
been initiated, Cardholder can receive money back after successful authorisation.
Chargeback - process of complaint management. It can be initiated by Issuer in case
Cardholder informs Issuer that he/she did not do the transaction or did not authorize
it, or goods were not delivered etc. The process is costly for Issuer and Acquirer but
ensures security of the system for cardholders.
Card-to-card transactions and payouts - the so called "payment" or "credit
transactions". In a standard purchase transaction money is transferred from
Cardholder to Merchant. In a card-to-card transaction or payout transactions, the
user gets money on his/her card or on the account linked to the card.

There are other important processes associated with payment systems and card transaction
processing, but let's stop here and take a short break to understand these critical processes.
Ranking of card issuing
companies
How to choose a BIN sponsor and card issuing partner?

Choosing a BIN sponsor or card issuer is a difficult decision for many partners. Most of our partners
do not come from the payment card business, so they learn by doing. In this chapter, we are going
to describe the key decision factors of choosing a card issuer and make a simple ranking that we
will be upgrading and updating in the coming months and years, as not all information is available
to us immediately. On purpose, we will not compare other companies to us, it would not be fair to
include Verestro - our goal is to educate in this article.

There are the following key decision factors in choosing a card issuing partner:

1. REVENUE SHARE - Cards issued for my users bring various revenue streams. Are they shared
with me?

Does the card issuer share 100% of interchange with me?


What is the currency conversion rate that the card issuer shares with me?
How can I impact and earn on ATM withdrawal fees?
How can I impact and earn on various consumer fees?
Can the partner help me with getting the Mastercard or VISA marketing and financial
support in the short and long run?

2. COSTS - Obvious point.

What are fixed and variable fees?


What is the level of fees in case of low volumes and high volumes?
Is there any opportunity to minimize costs as the business grows?
Read this article for more info on standard card issuing costs: Card issuing - financial

details

3. FUNCTIONALITY & SERVICE - a very important point. Critical in the long run.

1. Does the partner have mandatory functionalities?


Does the partner offer currencies that I need for my users?
What are other products that can increase usability or profit that the partner offers?
Maybe a loyalty program?
Any insurance offers and additional benefits that could be sold to customers?
Perhaps invoice scanning and expense management?
Maybe white label solutions?
Card reload mechanisms?
Payouts to cards?
etc.
Does the partner offer quick access to a developer zone or a test environment?
Does the partner make their APIs public?

3. SECURITY AND FINANCIAL STABILITY - a critical point. Maybe it should be the first one.

Is the partner a small start-up, burning money or a payment institution generating


profits? Can you imagine what would happen to your portfolio and users in case of
bankruptcy or hostile takeover?
Who are the shareholders of the partner? Are these venture funds or strategic, long
term investors?
Does the card issuer make their financial statements public?
Does the partner offer support in solving PCI DSS issues (Payment Card Industry
Data Security Standards)?
Is the partner audited annually?
Does the partner work with banks and other large financial institutions or focus only
on small, high-risk startups?

Here's an initial comparison of the best known card issuers in the European Union (grades: low -
high):

Name Country Revenue Share Costs Functionality & Security &


Service Financial
Stability

Treezor.com France Medium High Medium Medium

Swan.io Denmark Medium High Medium Medium

Dipocket.org Lithuania High Medium Low Low

Solarisgroup.com Germany Medium High Medium Medium

Wallester.com Estonia Medium Medium High Medium

Stripe USA Low High High High

Weavr.io Malta Medium Medium Low Medium

Verestro Poland Make your own Make your own Make your own Make your own
assessment assessment assessment assessment
Source: Financial Stability results based on 2022 or 2023 results available in Internet; all other data
from publicly available sources. Please make your own assessment.
Card issuing - financial
details
How can I earn from card issuing? This is a common question that is asked by our customers. Let
me explain the key financial areas connected with this business.

Indirect revenue or cost savings


Usually, the main reason for issuing cards in different segments is indirect revenue or cost savings.
The first question that you should ask yourself is connected with your use case. What can a
payment card bring to my customers or my business? The answer to this question is different for
various business segments and is the most important factor in defining a financial model for such
an operation:

If you are a bank, payment cards are obviously a core payment product that lets you earn
from various transactions, currency conversions, ATM withdrawals and other fees.
If you are a fintech wallet, it is obviously an important functionality because you
compete with banks. It can increase your revenue streams from the same areas as above.
If you are a crypto wallet, you want to offer to your customers a way to use digital
assets at brick-and-mortar shops and in eCommerce.
If you are an insurance company, you may want to send insurance in the form of a
virtual card with a particular transaction and geographic limit so that your customer could
immediately get necessary help.
If you are an investment wallet, where users store value in the form of shares or bonds,
you can offer payment cards to them so that they could pay using their shares at standard
shops.
If you are an eCommerce merchant or marketplace, you may be interested in using
payment cards as a way to send back money to your users after their claim so that they
could use this card for an eCommerce payment.
If you are a small, medium or large corporation, you may want to distribute cards to your
employees so that you limit costs of invoice processing and company invoicing.
If you are an HR agency, you can use cards as a tool to pay salaries to your employees
If you are a loyalty program owner, you may be interested in enabling users to use your
points and make purchases at any location in the world.
etc.

There are many use cases and this is the main value for you. You can charge additional fees for
this new service offered to your users, or you can limit your operating costs thanks to card
issuing. However, there are direct revenue streams and costs associated with issuing cards and I
will describe them below:
Direct revenues of card issuing
The following direct revenue is connected with card issuing and card transactions:

1. Interchange Fee - when your user pays online or offline at any merchant, there is a fee
called Interchange Fee that the issuer of cards receives for this transaction. The value of
this fee depends on the country, transaction type, card product type, etc. In general, it is
between 0,2% (for consumer debit cards issued in Europe) to 1-2% (for various types of
cards for transactions done on other continents). Make sure you check with your card
issuer or BIN sponsor how they share this fee with you - it is the most important revenue
stream.
2. Currency Conversion Fee - every card transaction done in another currency than
currency of a card account results in currency conversion. This action usually enables
charging fees. Typically, they are between 0,5% to 8% depending on card product,
country, currency, etc.
3. User fee - card issuers, banks, financial institutions usually charge various user fees for
using their payment card. Examples of such fees are: one-time fee for issuing a card,
monthly fee per card, annual fee per card.
4. Transaction fees - depending on a card product and a type of transaction, card issuers
charge users additional transaction fees. A very standard fee is an ATM withdrawal fee - it
is almost always valid because there are direct costs of an ATM withdrawal called ATM
Service Fee and these costs need to be covered. Sometimes card issuers charge POS or
eCOM transaction fees - for example 0,1% fee for every transaction done with a card.
5. Value added services - a card product enables you to charge additional services, i.e.
insurances, VIP support, concierge etc. that increase your revenue streams.

Direct costs of card issuing


1. One-time fee for card issuing - usually 0,1-1 EUR. This fee is charged at the moment of
card issuing. This fee covers costs of payment processors, various costs of operations
connected with issuing the first card.
2. Monthly fee per card - usually you pay 0,1-1 EUR monthly per issued card. This covers
both technical, regulatory and financial risk costs of card issuers.
3. Transaction fees:
per transaction (from 0,05-0,3 EUR) - depends on a type of transaction, region of
transaction etc.
per transaction value (from 0,01%-0,5%) - depends on a transaction value.
4. ATM service fee - very specific fee which is part of a transaction fee in fact. For every
ATM withdrawal, a card issuer needs to pay a fee which is transferred to an ATM operator.
Usually, it is in the value of 0,5-3 EUR + 0-1% from the transaction value.
5. 3DS operations fee - transactions in eCommerce require additional authentication. Such
an operation usually results in an additional fee charged by a card issuer (0-0,04 EUR per
transaction).
6. Apple Pay fees - Apple charges additional fees for using Apple Wallet. Those fees are
both per card quarterly and per transaction volume - different for POS transactions and
inApp transactions. We are not allowed to disclose the level of these fees.
7. Plastic card related fees - production, personalization and transport of plastic cards is a
serious operation that involves various costs. Typically, between 2-5 EUR per card
depending on customer location, type of card, etc.

These fees are usually charged by card issuers and BIN sponsors to their partners. They have to
charge them because there are various costs that we need to cover (this issue also applies to
Verestro and our BIN sponsors). The main card issuing costs are:

1. Payment scheme fees - Mastercard, VISA or any other payment organization charge a
lot of various fees for connecting with them and using their licenses and technology. This
is one of the biggest components of costs for card issuers.
2. Payment processors - this is our (Verestro's) role. To issue cards, you usually need to
hire external, certified payment processors. They charge a lot of fees for using their
technology. Examples of such processors are : Verestro :) , Paymentology, Fiserv, First
Data, Marqueta etc.
3. Card manufacturers and personalisation centers - if you issue or sell plastic cards,
you need to produce and personalize these cards. Companies like Austriacard, Thales,
Idemia charge fees for such operations.
4. Regulatory compliance costs - to become a card issuer in any country, you need to
have a payment license, get certification, fulfill necessary roles that are not present in
another business. This is a serious cost for card issuers.
5. Security costs - to work with payment cards and process them, you need to fulfill
various security requirements. The most important ones are summarized in the Payment
Card Industry Data Security Standards. They include not only internal actions but also
annual and quarterly audits that you need to perform to be compliant and offer secure
operations.

There are other possible revenue streams and costs connected with card issuing, but the ones
described above are the most important ones.

Thank you for reading.


Example of Profit & Loss
calculation in card issuing
Calculating profits and losses in card issuing is not easy, especially when various card issuers offer
different fee and revenue models. Below I would like to show a few examples.

Let's imagine we are a fintech wallet with 10.000 users and we would like to issue cards for these
users. The first step we need to take is to try to forecast key parameters of product, transaction,
revenue and cost assumptions:

1. Product
Product - Debit Business Mastercard card
Settlement currency - EUR
2. Transactions
Average number of cards in a year - 10.000
Offline POS transactions in Europe: Number of transactions per month - 5 ; Average
Transaction Value (ATV) - 30 EUR
Online eCom transactions in Europe: Number of transactions per month - 3 ; ATV -
40 EUR
ATM transactions in Europe: Number of transactions per month - 2 ; ATV - 100 EUR
Share of currency conversion transactions in Europe - 10% (transactions done in
Polish zloty, Czech koruna, Romanian Lei, Swedish krona etc.
Offline POS transactions outside of Europe: Number of transactions per month - 1 ;
Average Transaction Value (ATV) - 60 EUR
Online eCom transactions outside of Europe: Number of transactions per month - 1 ;
ATV - 60 EUR
ATM transactions outside of Europe: Number of transactions per month - 0,1 ; ATV -
100 EUR
Share of currency conversion transactions outside of Europe - 100% (transactions
done in Polish zloty, Czech koruna, Romanian lei, Swedish krona etc.
Share of registered ApplePay cards - 30%
Share of ApplePay transactions - 20% for online and 90% for offline contactless
3. Revenue
Interchange fee for business cards (fee from POS and eCommerce transactions; we
assume 100% of interchange stays with partner)
in Europe - 1.2%
outside Europe - 1.5%
ATM withdrawal fee - 0.5%
POS and eCommerce transaction fee - 0%
Currency conversion fee - 2%
Monthly fee per card - 1 EUR
4. Costs
One-time fee for an issued card - 0,4 EUR
Average monthly fee per card - 0,3 EUR
Fee for offline POS transactions in Europe - 0,10 EUR + 0,1%
Fee for online eCom transactions in Europe - 0,10 EUR + 0,11%
Fee for ATM transactions in Europe - 0,9 EUR + 0,3%
Fee for offline POS transactions outside of Europe - 0,3 EUR + 0,45%
Fee for online eCom transactions outside of Europe - 0,3 EUR + 0,5%
Fee for ATM transactions outside of Europe - 0,3 EUR + 1.2%
Currency conversion fee - 0,5%
Apple Pay active card quarterly fee - 0,25 EUR

Let's do quick calculations.


Please treat it as example and make your own calculation. There will be many dependencies
connected with segment, type of portfolio, detailed pricing, volume estimations etc.

Taking into account the above assumptions, you could earn 30.933 EUR monthly and 371.192 EUR
annually on such a portfolio. Seems high? Interested what cost of investment is needed? Contact
us.
Thanks for reading.

PS. If you are interested in receiving an Excel file related to these calculations, let us know at
sales@verestro.com.
Regulatory and license
impact on card issuing
Legal issues related to regulatory or payment scheme rules often arise in questions we receive
from our partners and clients. In this article I would like to summarize key dependencies,
limitations and rules that have a very important impact on payment accounts opening, card issuing
and also acquiring or money transfer activities.

When you are launching a payment institution, you have several areas to cover. One of the most
important of them is a legal and rules area. Usually this impact can be divided into three main
groups of activities: legal requirements, anti-money laundering requirements (which is a specific
type of legal requirements) and payment scheme rules. Let me deep dive into each of them.

Legal requirements
To operate payment activities, almost in any country you need to get a payment license. There are
various types of payment licenses depending on the country, so here I would like to summarize the
most important details. In many cases you can hear about EMI (Electronic Money Institution
license), Bank (Banking license), Credit Institution, Acquiring Institution etc. These requirements
are usually connected with operational activities that the company needs to fulfill to perform
payment operations for other entities. They consist of:

Regulatory requirements in the areas of security, Know Your Customer, AML, liquidity
operations, organizational structure etc.
Audits performed by regulator
Risk of penalties for both the company and sometimes persons involved in payment
companies
Outsourcing activities compliance
Local laws that forbid processing customer or transaction data outside of the country
etc.

It is important to understand details of such requirements and to follow changes of law and rules
on a regular basis.

From the business point of view those requirements force us to :

Officially register contracts with various partners at the regulator


Get an approval for particular actions outsourced to partners
Perform regular monitoring of payment activities done with cards issued for users of our
partners
Follow the national and EU sanction lists
Being ready to block any transaction, account or card at any time

For our partners - just make sure that you follow the rules we inform you about. They are critical for
our activity, licenses, so in fact they are securing your business.

AML and KYC requirements


AML (Anti-Money Laundering) and KYC (Know Your Customers) are part of legal requirements but it
is worth presenting them as a separate group because they usually have the biggest impact on
operations. The main goal of these rules is to ensure that payment organizations are not used to
launder money, support terrorist or illegal activities. They also allow governments to monitor a
payment activity area which may be helpful in fighting crime activities.

Key areas of impact of those requirements can be summarized as follows:

Payment institution is obliged to perform KYC requirements as defined by the regulator -


usually consisting of collected proofs of user identity verification (documents, videos,
selfie, talks, and other measures)
In case of business customers and business accounts, not only Board Members but also
Beneficiaries of the companies need to go through a KYC and sanction list screening.
Beneficiary is defined usually as a person with above 25% shares
At any moment a payment institution must be ready to present these documents to the
regulator
Persons and entities placed on sanction lists cannot use services of a payment company
Active monitoring of payment transactions for all users is required
Sometimes proofs of income can be required

It is interesting that AML and KYC requirements do not block us from issuing cards or opening
payment accounts for partners located outside the European Union with our payment companies
licensed in the European Union. We are allowed to perform payment activities for Brazil, US, China
citizens, as well as the Polish, German or French ones.

Make sure that you collect user documents and provide them during the user registration to us to
fulfill those requirements.

Payment Scheme requirements


Payment Schemes (Mastercard, VISA or others) have separate requirements that must be followed
by their partners and licensees. These requirements are similar to the previous ones but not always
the same. Key requirements that do have impact on business are:

We are licensed for a particular country or region. In our case it is the European Union
countries (in fact the European Economic Area, which is a slightly different area). It means
that with our European licenses we can issue cards for people residing, having addresses
or working in the European Union. In case we would like to issue cards for people or
entities from outside the European Union we have to get special Mastercard approval
which is not impossible but may be difficult to achieve.
We must follow payment scheme requirements on sanction lists and scan users and
beneficiaries against OFAC (US Office of Foreign Assets Control) and United Nations
sanction lists.
We must be ready to follow Mastercard technical and rules requirements that sometimes
may have impact on technical setup and use cases of your users
In case of mandates we need to be ready to implement on time necessary system
updates to reach compliance with the Mastercard network

Problematic areas
Usually problems in a business discussion come in the following areas:

Can we issue cards for non-EU citizens? Answer: generally yes, but sometimes there may
be problems, the majority of your business must be in Europe, your user addresses or
office should be in Europe etc.
What documents do we need to transfer to you during registration? Answer: selfie,
international passport is usually a minimum

Following regulatory, AML and payment scheme rules is critical for payment companies. We do not
have a choice. This is part of the game of card issuing and we must follow requirements. However,
it is good that such rules exist. They make our customers' money safer and minimize much bigger
risks of running or supporting illegal activities.

Thanks for reading.


KYC and KYB requirements
in card issuing
KYC (Know Your Customer) processes usually raise a lot of questions. In this article, I would like to
summarize the most important decision points and requirements.

KYC regulations are directly connected with Anti-Money Laundering (AML), regulatory and
sometimes with payment scheme requirements. In general, every payment or banking institution
must be aware who its customers are, should know the source of its customers' funds, and should
have information about the ways customers use money held by the payment institution. Regulators
require that payment institutions know and monitor this in order to limit the risk of supporting
terrorist or illegal actions.

The main question in every project is: "Who is the owner of the money on account?" We can have 2
situations:

1. CONSUMERS - If the consumer is an owner of the money on account, the KYC process has to
happen. Usually it means that the user (consumer - not a company) needs to provide an ID
document or passport and selfie, meeting or video call needs to happen to make sure that
consumer is a real person signing a contract with a payment institution. There are various
additional verification ways that a payment institution may require, but those are the key ones.

2. BUSINESSES - If a company is an owner of money, the KYB (Know Your Business) process has
to happen. Usually it means that the user (company owner, manager etc.) not only needs to
provide an ID document and make a selfie or a video call, but the payment institution needs to
verify beneficiaries (the owners of more than 25% of shares in the company).

In both cases the payment institution is obliged to check whether the consumer, business manager
or business owner is not present on various sanction lists, i.e. OFAC or UN sanction list.

These rules are critical and in fact all other implications are outcomes of them. In projects
connected with launching Payout to Cards, the very first question that we need to answer is : "
Who is the owner of the money on account?" If the consumer is an owner of the account
(scenario 1) - the consumer needs to go through the KYC process. If the business is an owner of the
money on account (scenario 2), the KYB process will have to happen and there will be no additional
KYC.

There may be non-standard situations that will require some analysis. Let me present a few
interesting scenarios:
Lendtech - a company that provides loans to consumers. Let's imagine that this company
is giving a loan of 1000 EUR to a consumer. We can have a project in two versions:
if the consumer receives a loan on his/her personal card - then we have the KYC
requirement.
but if a card is just a part of Lendtech account and formally the consumer gets a loan
at the moment he/she takes out money from the card account - we do not have any
KYC requirement; we just need to do KYB for Lendtech. It can simplify user
acquisition a lot.
Insurance - an insurance company sends insurance value to users after a claim process
or just after an accident:
if the user receives a gift card with 1000 EUR, which is the value of the claim, and at
the moment of receiving the card, 1000 EUR on this card becomes his/her ownership
- we have the KYC requirement for the user.
but if the user receives a card with a limit of 1000 EUR and when they pay - they use
the insurer's money to cover costs of the claim, we do not have any KYC
requirement. KYB will be enough for us.
Money transfer company - let's imagine that the company sends a virtual card with
1000 EUR from Europe to the receiver in Singapore:
if the user receives a virtual gift card, and 1000 EUR belongs immediately to this
user, we have to do KYC of this user
however, if users receive a virtual card with a limit of 1000 EUR and the money
becomes theirs the moment they pay or withdraw funds from the card, KYB is
sufficient. KYC is not required.

As you can see, there can be different approaches to KYC and KYB requirements, so it is worth
reviewing the legal structure and thinking about how to improve the user experience in such
projects.

Thanks for reading.


PCI DSS & other security
requirements
Very often customers ask questions connected with security. In this article we would like to
summarize key requirements connected with Payment Card Industry Data Security Standards
(PCI DSS). There are other rules that we and our partners need to follow (like GDPR for example)
but it will be the topic for another article.

The most important question that needs to be answered before going into details of PCI DSS
requirements is - Am I actually processing payment card data?

Key PCI DSS requirements mentioned below apply only in case that the partner has access to card
number (PAN - Primary Account Number), expiry data or other related card data. If the partner
does not touch them, if the partner cannot see those numbers there is only one requirement - a
simple Self Assessment Questionnaire (SAQ) needs to be fulfilled to confirm that the partner is
compliant with PCI DSS requirements.

It is very important that you choose the correct way of integration with the card issuing platform. If
you use our mobile SDKs or white label products, usually you will not have access to card data and
will be able to approve your project just after fulfilling SAQ mentioned above. So please consider
this way of integration to avoid additional costs and risks of PCI DSS compliance. However, if you
connect via API, which is a usual way of integration, you will have to comply with security rules.
Please read this section twice. This is the most important - choice of integration method will be
decisive if you have to or not go through annual external audits and all hassle connected with PCI
DSS.

Assuming you do process card data, depending on what your role is, different levels will be applied
to you. You can be a merchant or a service provider. In simple terms, if you do the work for
yourself then you are a merchant if you want to further provide the service (intermediary) you are
most likely a service provider. In card issuing projects you will rather be a service provider
because you offer cards to your users. Let me give some examples:

Service Provider - wallet, crypto wallet, money transfer organisation offering cards to own users
etc.

Merchant - an insurance company that wants to use a card to send money to their users, a
lending company that wants to send a card to users, a corporation or SME giving business
payment cards to their employees etc.
Who is according to PCI DSS "Merchant"
PCI DSS, or the Payment Card Industry Data Security Standard, defines a merchant as any entity
that accepts payment cards (such as credit cards and debit cards) as a form of payment. The term
"merchant" can encompass a wide range of businesses and organizations, including traditional
retail stores, e-commerce websites, restaurants, hotels, and service providers that handle
cardholder data.

Under PCI DSS, merchants are required to comply with a set of security standards and practices to
protect the payment card data they handle. These security measures are designed to ensure the
confidentiality and integrity of cardholder data, reduce the risk of data breaches, and protect both
customers and the payment card industry as a whole.
PCI DSS compliance requirements can vary depending on the merchant's size and the volume of
card transactions they process. Merchants are typically categorized into different levels based on
their transaction volume, with higher-volume merchants facing more stringent compliance
requirements.

There are 4 levels of compliance and requirements depending on volumes of cards and
transactions.

Level of PCI DSS Your business does What you should do

4 · Less than 20 000 eCommerce · Complete an annual Self-


transactions per year Assessment Questionnaire (SAQ)
· Less than 1 million other · Conduct quarterly network scans
transactions per year by an Approved Scanning Vendor
(ASV)

3 · 20 000 – 1 million transactions · Complete an annual Self-


per year Assessment Questionnaire (SAQ)
· Conduct quarterly network scans
by an Approved Scanning Vendor
(ASV)

2 · 1-6 million transactions per year · Complete an annual Self-


Assessment Questionnaire (SAQ) or
ROC conducted by a QSA
· Conduct quarterly network scans
by an Approved Scanning Vendor
(ASV)

1 · 6 million + transactions per year · Complete an annual internal


audit
· Conduct quarterly network scans
by an Approved Scanning Vendor
(ASV)

Who is according to PCI DSS "Service Provider"


According to the Payment Card Industry Data Security Standard (PCI DSS), a Service Provider is
defined as any business or entity that is not a payment card brand (such as Visa or Mastercard)
and is involved in the processing, storage, or transmission of payment card data on behalf of
another organization. Service Providers play a crucial role in the payment card ecosystem, as they
offer various services to help businesses accept and process card payments more effectively and
securely.

Service Providers can include a wide range of businesses, such as:

1. Payment processors
2. Payment gateways
3. Hosting providers
4. Managed security service providers
5. Data storage companies
6. Point-of-sale (POS) system providers
7. Customer relationship management (CRM) software providers
8. Software-as-a-Service (SaaS) providers

Service providers are categorized based on the services they provide and their interactions with
payment card data. Here are some common classifications of service providers based on PCI DSS:

Level of PCI DSS Your business does What you should do

2 · < 300 000 transactions per year · Complete an annual Self-


Assessment Questionnaire (SAQ)
· Conduct quarterly network scans
by an Approved Scanning Vendor
(ASV)

1 (Verestro has 1 level of PCI DSS) · > 300 000 transactions per year · Complete annual internal audit
conducted by a Qualified Security
Assessor (QSA)
· Conduct quarterly PCI ASV scans

Verestro has the 1st level Service Provider of PCI DSS, which means that we have to go through
quarterly PCI ASV scans and an annual external audit performed by certified PCI DSS assessors. In
accordance with the principles of PCI DSS, Verestro is obliged to check if the partner is working in
compliance with the PCI rules, so we will be checking what the level of transactions and cards in
your case is.
So let's remind our two possible scenarios:

Scenario 1 (The partner does not have any access to unencrypted PAN numbers) -> THIS IS THE
BEST AND RECOMMENDED SCENARIO. In this scenario you will most likely use our SDKs and admin
panel and full encryption of card data. Verestro will guide which Self-Assessment Questionnaire (
SAQ A for merchants) is appropriate and ask a few questions (from SAQ). The document will have
to be signed by the partner.

Scenario 2 (The partner can access unencrypted PAN numbers) -> in this scenario:

Verestro will provide a Self-Assessment Questionnaire (SAQ), and ask a few questions. The
document will have to be signed by the partner.
The partner will perform quarterly PCI ASV (Approved Scanning Vendors) scans
(cost around 1k EUR quarterly or less) - The partner can choose any provider from the PCI
Security Standards Council (PCI SSC) or Verestro can recommend a supplier.
Until the partner reaches 0,3 mln transactions/interactions annually with PAN numbers,
the partner does not need to undergo an annual internal audit (in extreme situations, it is
possible to require PCI internal audit from the partner).

If the partner plans to achieve 0,3 million transactions/interactions, there are two options:

either the partner will move to a scenario that does not touch card numbers using some
technology changes
or the partner should perform an annual internal audit done by a PCI auditor (QSA)

If you would like to discuss your requirements in more detail and receive more information, please
contact us.

Thanks for reading.


Master balance and
collateral in card issuing
projects
During the implementation of card issuing projects with Verestro and our partner payment
institutions, we receive questions about liquidity management and collateral in card issuing
projects. Let me summarize and explain the key dependencies.

There are two important points that need to be taken into account:

1. Collateral - this is a dedicated amount of money and account which needs to be transferred by
our partner to our account to cover costs of payment risks and collateral that we need to pay to
Mastercard or VISA. Usually it is between 3-5 days of transaction volume. The collateral is non-
refundable until the end of the project and may grow in time together with the volume of
transactions. If we do not take collateral, there is a risk that in case of growth, we will have to block
the partners' transactions because we will not have enough liquidity at Mastercard or VISA
accounts.

2. Master balance - it is an account (in other words cash balance) dedicated to our card issuing
partners where our partner stores his own money which covers fees paid to Quicko and/or
transaction settlement in case of working with external balance API. There are two possible
situations that affect the amount of the master balance:

Scenario 1 - In case External balance API is used which means that partner keeps
information about user balance and every transaction authorisation is routed to
partner for approval. In such a case we have to keep the Master balance of the
partner up to the amount of transactions. Every transaction authorisation is verified
by the partner but also on our Master balance account. A day later we have to settle
money for this transaction with Mastercard so we must have enough cash on Master
balance to cover this transaction amount. Every day or any time our partner
transfers additional money to the Master balance to make sure that there is enough
liquidity to cover costs of transactions of their users. This means that the amount on
the Master balance is high enough to cover transactions of users during a day, week
etc.
Scenario 2 - In case internal balances are used, we have a situation where all users'
money are kept at our payment institution. It means that the partner does not need
to provide additional funds to cover transaction volume. In such a case the partner
needs to transfer just an adequate amount to cover the amount of transaction and
card fees to be paid for card issuing activities.

In all card issuing projects both collateral and masterbalance exist so please make sure you are
aware of differences between those two definitions.

Thanks for reading.


Pay with Rewards, Pay with
Points
There are multiple use cases where you can use virtual Mastercard payment cards. Let me
explain how it works, how you can offer your users a loyalty program or another point-based
program to make transactions at any merchant location.

Let's imagine you provide a loyalty program for your users. You can also have any other point-
based offering that enables rewards. You are interested in launching a program in which your users
will be able to pay at any merchant location with a Mastercard virtual card.

In such a case you could use our card issuing services with External Balance API. It would work
in the following way:

1. We launch a business card program for you. We perform Know Your Business
verification with you as a company. Every card issued in the program will be in fact a
payment card of your company.
2. You integrate with our Lifecycle API in order to register users and request cards
3. You integrate with card issuing API to manage cards and with External Balance API to be
able to authorize transactions.
4. We would also integrate your solution with Apple Pay and Google Pay, and the cards
would have your visual. Thanks to this, your users could easily use them for any payment.
5. You have to decide what the value of a single point is. You will receive from our system
authorization for 20 EUR and you will have to approve or decline this transaction.
6. We will ask you to open an account at our partnering payment institution - you will
have a Master balance which will cover direct settlement of payment transactions. You
can reload Master balance every day.
7. From that moment users will be carrying your payment cards in their Apple Pay and
Google Pay wallets and every transaction will be routed to your system for
authorization. At the moment of transaction we will use Master balance to cover the
transaction cost and you will charge point balance of the user.
8. Additionally, you could limit merchants where users can make transactions and get an
additional fee from the merchant for enabling transactions at a particular merchant.

In today's payment world, such a project is easily available and not difficult to implement. There is
a simplified integration and after several weeks you can go live with a new functionality.

Thanks for reading.


Multicurrency cards - 3
implementation options
Multi-currency topic is an interesting and important concept of card issuing that usually requires
some explanation. Because of the very big market of currency conversion and usually very high
fees of universal banks connected with international transactions, it became popular to implement
multi-currency cards. Actually the first Revolut use case, heavily promoted several years ago, was
connected with this topic. So let's go into details.

There is actually one problem that we want to solve when thinking of implementing multi-currency
cards - how to enable the best and most effective card payments in an international
environment? There are various approaches to this problem:

Scenario 1 - multi-currency cards and accounts


In this example we offer users multiple payment accounts in various currencies.

1. The user gets a single payment card connected with all accounts
2. In case the user pays with currency X, the authorisation system recognises transaction
currency and debits account of currency X
3. In case there is no money on this account, system debits another (default) currency

This example is very often used, but it has a few disadvantages. The first is that the user must
perform currency conversion before. It is an action before his/her travel and actually it is an
unnecessary action from the logic's perspective. It should be more convenient for the user to have
one account and cheap currency conversion during every transaction. But usually consumers like
the solution because they can manage this currency problem in advance, see FX rate and can
make decisions on how much money to convert.

Implementation of this scenario is not easy because card issuing companies either need to enable
multi-currency functionality with Mastercard / VISA or to implement multiple settlement accounts
with payment organizations and manage conversions accordingly based on transaction currency.
There are additional fees that Mastercard and VISA charge for this service which can make this
implementation costly.

Scenario 2 - currency conversion on a single account


Another way of solving the currency conversion topic is to think about how to enable the cheapest
conversion during a transaction. In this example the user does not have to convert currency before
his travel. He just uses his card while traveling. I personally like this approach the most because it
is easier for me but in reality many customers prefer scenario 1.

In this scenario, to have dynamic rates, there is a need for online FX API integration and dynamic
management of rates during authorisation. Usually card issuers use static conversion rates offered
by Mastercard and VISA but this leads to some additional costs and margins. Ensuring dynamic
currency conversion during authorization and proper conversion management may be difficult to
achieve.

Scenario 3 - multiple cards for different currencies


The third way of managing the multi-currency topic today in the virtual card environment is issuing
multiple cards to multiple accounts in various currencies. In today's world this is easily achievable
as the cost of card issuing went heavily down. It works in the way that users have several cards,
connected with various accounts and card visuals, visible in Apple Pay or Google Pay with the
currency of a particular card. The user can choose a card which is the most convenient for him/her.

In this scenario we need to offer an inexpensive currency conversion mechanism as the user needs
to manage balances on each account separately and perform conversion in advance.

This is actually the cheapest scenario of implementation.

While thinking about the multi-currency topic, please consider various scenarios and ways of
solving problems. Sometimes the default plan (scenario 1) can be very costly from the transaction
processing perspective because of additional fees of payment schemes.

Thanks for reading.


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.


How to prepare for a card
issuing project?
Do you want to issue cards to your users? In this article we describe what is required on your side
to implement virtual or plastic cards in your applications.

Let's imagine you are a fintech, crypto wallet, lendtech or any other company with a concrete
target segment, some or thousands of users and you have a mobile application for your customers.
You have decided to go live with card issuance in order to increase revenue and user loyalty. Below
we describe the main decisions and steps you need to take to get ready for a card issuing program:

1. Decide on a card issuing partner - check out other articles we have on this topic in the
Knowledge Center. Make sure that the partner has the necessary functionalities, legal
requirements and flexibility that you can accept. Check your partner's financial standing.
Contact us for more details.
2. Analyse and describe your use cases - describe user flows, develop some initial
graphs of how key processes will work. Focus on user onboarding, Know Your Customer
steps, card generation and activation, card management and transaction flows. Read the
Developer Zone requirements during this step to make sure you are ready to integrate
without difficult customisations.
3. Check the legal environment - try to analyse and understand the regulatory
environment. Check if you can fulfill KYC requirements and how you can collect data from
users. It is important that you submit a user selfie and document photos to the card issuer
during the verification process. If you are working with us, please make sure that you
have a European entity or branch in the EU to sign a contract with us for card issuing.
4. Verify API integration - go to the Developer Zone and analyse APIs or SDKs that you will
have to connect to. If you want to avoid PCI DSS audits and associated costs, consider
using SDKs. It is highly recommended if you have a large group of users.
5. Make P&L analysis - consider the revenues from card issuing and the costs of this
product. Make sure you understand unit economics. You can use articles in our Knowledge
Center to start this work. Choose an affordable partner - do not think that if something is
more expensive, it is better in quality. The card issuing business is a cost-based business
where low level unit economics matter, especially cost per card and cost per transaction.
Revenue share from interchange fees or currency conversions is even more important
than costs.

If you have checked these points, you are ready to sign a contract. Contact us sooner, let's work
together. We can advise you on many of these points to build the best possible program for you.
We have extensive experience in more than 30 countries on 5 continents. Make use of this
knowledge to get started.
Thanks for reading.
How can I reload a payment
account or card?
There are many ways of transferring money to payment accounts or cards. In this article we would
like to explain how it can be done with Verestro and in other cases.

Let's start with definitions so that we speak the same language. What is a payment card? What is a
payment account? What is an IBAN? It seems simple, but in fact many customers use these words
in a different way.

Payment Account - it is a place in the system of a payment institution which holds


information about money stored for a particular customer. Just it - a kind of a Record ID in
a payment institution. It is not an IBAN, it is not a card.
IBAN - IBAN is a payment account number in an international banking standard. This
number helps sending wire transfers to a Payment Account.
Payment Card - it is another number (PAN - Primary Account Number in the terminology
of Mastercard and VISA) connected with a Payment Account and usually another payment
instrument connected with a Payment Account. The Payment Card is a tool to pay using
money on a Payment Account and sometimes it is a way to transfer money to a Payment
Account. To be honest, I do not know situations where a Payment Card works without a
Payment Account. In some countries (like USA) usually a Payment Account is not used in
common discussions, but in fact there is always a Payment Account connected to a
Payment Card.

Once we know those 3 definitions, let's look at the ways of transferring money to a Payment
Account, which in other words could mean ways of reloading a Payment Card. There are several
ways that we can use:

1. Bank transfer to IBAN - in such a case the user is sending money from an external bank
account to our Payment Account, using an IBAN connected with our Payment Account.
Usually it is a very easy, fast and effective way of transferring money in case of domestic
transfers. It could be a costly way of reloading an account if the customer is abroad.
2. Payout to Card - in such a case the user is sending money from another bank or money
transfer organisation using a Payment Card number issued by Verestro and our issuing
partner. The customer is using Mastercard Moneysend or VISA Direct to transfer money
from another account to their Payment Account at Verestro. Usually it is very fast but not
cheap way of money transfers.
3. Card-to-card - card-to-card transfer is used when the user provides at external service
another Mastercard or VISA card and transfers money to a card issued at Verestro. In such
a case a funding card (a card issued by another bank) is debited and our Payment Card is
credited, which means that money will appear on the Payment Account soon.
4. Reload by another card via PSP, Google Pay or Apple Pay - in any wallet of our
partners we can provide functionality called Paytool which enables charging another card
and sending money directly to the user's Payment Account. In this situation a funding card
is charged as if it was an eCommerce transaction. The user's Payment Account can be
reloaded quickly.
5. Reload by partner - in many cases our partners can use their own funds to reload the
user's Payment Account. Examples of such situations are lending institutions that issue a
card and reload a Payment Account with a loan amount. Similar example could be issuing
cards for insurance related claims - in such a situation our partner (insurance company)
adds money to the user's card and sends the card to the insured person. Usually such a
reload happens via MasterBalance which is an account that we hold for our partners and it
contains their money. This account can be used for a reload, as is usually used for
transaction processing.
6. Reload by crypto assets - in some cases it is possible that our partners send crypto
assets and we will convert them in cooperation with our partners into FIAT currencies to
reload the user's account.
7. Openbanking - our partners can use open banking PIS (Payment Initiation) messages to
transfer money to the user's Payment Account. We can help with such reload tools using
our Paytool product.

Those are ways of reload we use today. We are happy to work on other ways of money transfers
and enable new ones.

Thanks for reading.


Card Lifecycle Management
Once launching card issuing projects, our customers usually forget that it is a long-term activity
that requires constant verification and improvements. It is very important that you understand and
manage your card holders and use best practices in card lifecycle management. Let me summarize
key activities from a timeline perspective.

Stage 1 - choosing a card issuing partner

Obvious step. Everybody focuses on financials and technical integration. Very few people check
value-added services and other products. Almost no one is aware of PCI DSS & other security
requirements that will make your life easier on stage 4 and later ones. Another common mistake is
that you do not check the financial stability of your card issuing partner as if it is not important for
your business and users.

Stage 2 - implementation

Obviously important. No comments. Check Dev Zone and implement. Make sure your developers
read specs carefully. Make sure you understand AML and KYC regulations so that you can comply
with rules and the project can be built on strong fundamentals. A common mistake is not to
consider Stage 4 - card lifecycle management processes are forgotten.

Stage 3 - launch

Everybody focuses on this moment, plans campaigns, distributes cards. And usually this is the last
implementation step of this new product. It is a mistake.

Stage 4 - card lifecycle management

Once you are up and running, it is very important that you are able to monitor your portfolio,
create reports, organise personalised campaigns and manage your portfolio in a very active way.
There are several rules to follow in order to maximise your portfolio's earnings and performance.
The most important ones are summarised below:

Portfolio Manager - have people that will be responsible for the management of your
portfolio. 1 person is enough at the beginning. Make sure these people understand goals
and work to make your cardholders active
Reporting system- make sure you have a flexible reporting system that gives you
information not only about the number of issued cards and transactions, but more
importantly on the behaviour of various customer groups:
have reports how many customers used the card after 1-2 days, be able to find the
user IDs
have reports with customers that used the card after 5 days, 15 days, 30 days
have reports on inactive customer groups
Actions - be ready to act basing on the user behaviour
once you see that your customer is not using the card after 1-2 days - send him/her
a notification or an educational reminder
once you see that the customer is not using the card for 15 days - maybe you should
send a small digital gift to the customer and deliver it if he/she starts using card
if you see an inactive customer after 30 days - ask them why they are not using the
card; maybe you will get a correct feedback
Reporting - again and again check if your actions work correctly. What is their success
rate? How are your customers changing their behaviour?
P&L analysis - make a detailed analysis from a financial perspective, incentivise users to
do transactions that are bringing more revenue, think of increasing monthly fees for non-
active users
Quality reporting - check the quality of your services, ask users for feedback regularly,
collect information, analyse it, make actions to improve
Value-added services - think of launching new services that can improve performance
of your portfolio. Maybe a voucher-based ending, card-to-card money transfers, loyalty
programs etc. Ask us for best practices and tools that are easy to use.
Education (super important) - never underestimate the importance of educational
messages. You can teach customers how to use the card on the internet, tell them how to
tokenise the card in Apple or Google Pay, show them how to pay at ATMs. Card issuers
tend to forget how cheap and profitable it is to work on user education. Do not assume
that everyone everywhere uses payment cards the way you use them today. People
sometimes do not know how to use 3DS, they are afraid to use it, etc. Work on that.
Learn, change, improve...

Card issuing is a long-term activity. Please do not think that you will launch it and everything will
work properly. You should be constantly working to attract more users and teach existing users
how to use the cards so that they add real value to your business. Good luck!

Thanks for reading.


VISA or Mastercard?
Sometimes our customers ask if it is better to issue VISA or Mastercard cards. In this article we
would like to answer this question.

Main payment schemes


There are two main payment schemes in the card area that have almost monopolized global card
business - VISA and Mastercard. Next to them there are several local schemes, sometimes going
global that are also worth thinking of in more sophisticated global projects (like UnionPay China,
JCB Japan, EC Karte Germany etc.) but in general in majority of projects you will do the business
decision if you prefer to issue VISA or Mastercard cards.

In one sentence the answer is - usually it does not matter. But if you go into details, depending on
the country or type of the program there may be some important differences worth considering.

Key decision points


Below we present some important decision points:

1. Financial and marketing support - depending on the country and type of program
VISA or Mastercard can decide to support your program financially or from some
marketing assets. If so, it makes sense to consider this as an important factor in the
decision making process. Check with your card issuing partner if there are such
possibilities.
2. Interchange differences - in some countries (outside of the European Union) there are
slight but important differences in Interchange Fees which in the end means that you can
earn more from every transaction. Check with your card issuer if such a situation exists on
your market. If you are going to offer cards globally, it may also be possible that inter-
regional (inter-continental) transactions will be more profitable in one payment scheme.
So it is worth checking.
3. Cost factors - usually fees connected with a card issuing program will be dictated by
your card issuer or BIN Sponsor but in some cases a card issuer may have different fees
depending on the cost of VISA or Mastercard transaction fees.
4. Special local or global card benefits programs - both Mastercard and VISA are
developing various loyalty, discount, value added services that can make your program
more interesting for users. In Poland, for example, Mastercard is running a very attractive
card benefit and loyalty program called "Priceless Specials". It is worth checking as it may
be an important value added for your portfolio and users that may be much more
important than any financial details.
5. Brand and acceptance - in 95% of countries there is no visible difference in acceptance
and brand between VISA and Mastercard. But in some cases it exists. For example if you
are going to issue cards in Hungary - Mastercard is much more popular and customers are
used to it. It is worth checking before making a decision.
6. Educational and consulting support - it can be valuable help. In various projects,
countries or regions payment schemes can have services or people that can help you a lot
in defining a good value proposition and important details of a card issuing program. This
may be very valuable as very often employees of Mastercard and VISA are very
professional, have a lot of knowledge and can help you in developing your portfolio. If you
have such support, try to use it.
7. Shareholding connections - in some cases (like Verestro) one of the payment
organizations (in our case - Mastercard) will be a shareholder of your partner. It may be
very valuable as you will have in-depth support of the payment scheme and card issuer. It
may be useful in various situations, difficult cases connected with rules etc. Make use of
such cases, if you can.

Conclusion
Those are the main differences. It is worth considering. In the majority of cases your partner in
card issuing will have some preferences and sometimes there will be no choice. But it is certainly
worth considering when deciding which card issuer and payment scheme to choose.

Thanks for reading.


Card Benefits in card issuing
projects
Once you are launching your card program it is important to think about additional benefits that
you can deliver for your users or products that can increase the value of your program. In this
article we will show a few ideas and examples that you can use to enhance your card issuing
project.

How to strenghten your card issuing program?


Education and messaging - the most important but very often forgotten. No cost
benefit. Just start teaching your users how to use cards, how to behave in a secure way,
how to pay on the internet, how to connect to Apple Pay or Google Pay etc. Build ways or
use our white label ways of communication. It will pay back for sure.
Enable new ways of payments - enable new ways of payments for your users. Teach
them how to use their card in a friendly, secure, internal environment. Maybe they can
buy something on your platform, maybe you can enable money transfer from cards etc.
Thanks to such activities you will teach them how the card works and what they can
experience. You will lower the level of fear and risks they may fear at Point-of-Sale.
Insurances - think of launching a program with insurances. This became very popular 10-
20 years ago in the card business. Many banks give users additional insurances that they
can buy in their apps. Insurance is an ideal product and card benefit because it increases
security feeling among your users. Examples of such insurances are eCommerce payment
extended insurance, lost & theft insurance, travel insurance etc.
Point based loyalty program - think of launching a point based loyalty program or join
an existing one. We are using the Priceless Specials program done by Mastercard. This
can be a strong added value that you can communicate. You can also increase revenues
thanks to it and increase cross-selling if you start giving points to users for using non-card
based services that you are selling. It may seem difficult to implement but actually it is
not.
Voucher based loyalty program - once you have a growing number of users you can
start arranging special promos with eCommerce or offline merchants. We can help with it
as we are building a network of such partners. Thanks to such activities your users will get
additional margin or cash back and it will increase retention and happiness of your
customers.
Premium cards - maybe it is worth thinking of launching new gold, platinum or World
Elite cards for your users. Maybe you could offer much better VIP service, together with a
concierge for much higher fees. It is very popular among banks and it is one of the easiest
ways to increase profitability of the portfolio.
There may be more activities but these are the ones that you can implement relatively quickly in
order to offer better service and increase revenue.
Prepaid, debit or credit cards
- the main differences
Before launching a card issuing program, our customers consider which card product to use. In
this article we will summarize the key differences and considerations.

There are three main groups of payment cards: pre-paid, debit and credit cards. Below we
summarize the most important differences.

Prepaid cards
user has to reload a card account to use a card (like in debit cards by the way)
you can issue anonymous, non-reloadable gift cards
in some cases merchants block BINs of prepaid cards more often than for debit or credit
cards
you can have consumer and business prepaid cards
in many countries, from legal perspective, there is no difference between prepaid and
debit cards

Debit cards
This is the biggest group of cards in the world:

user has to have a payment account or current account connected with a card
user has to go through a KYC (Know Your Customer) process
user has to reload a payment account to use card
usually you cannot issue anonymous cards, because in general they are always reloadable
sometimes, if you give a loan to your customer, a debit card can work like a credit card
you can have consumer or business debit cards
you can have Gold or Platinum debit cards

Credit cards
user applies for credit and gets it in the form of a card
usually connected with a revolving credit (something like credit line) and a grace period
(no interest for 40-50 days)
because of the credit, the user needs to go through KYC and credit scoring, so it is more
difficult to issue than prepaid or debit cards
you can have Gold, Platinum or World Elite credit cards
you can have consumer or business credit cards
usually an interchange fee is a bit higher than in case of debit cards
sometimes approval rates for transactions are higher, some merchants (car rental) require
credit cards from their customers
because credit line is connected with this product, usually it is more profitable than a
prepaid or debit portfolio

These are the main differences between the above mentioned products. In most cases, you should
be thinking about debit cards because they give you the same benefits as prepaid ones, and you
can convert them into credit cards by giving loans to your customers.
Tips to avoid problems when
implementing card issuing
So you have a good business case for issuing cards for your customers and you found a perfect
vendor who can provide formal and technical services in this area. Right after signing the contract
you’re ready to implement. What now?

Now it’s time to make sure that the implementation will be as smooth as possible and you and your
team won’t get stuck on some of the common problems that may happen in the project. Of course
each vendor has his own approach, but let us explain how to avoid some of them based on
Verestro’s experience.

Preparing everything for you takes a moment


Depending on your particular setup we will need 4-8 weeks to prepare everything for you. From
dedicated environments so that your customers and their cards will always be safe and secure, to
ensuring that you will be able to use the cards in Apple and Google wallets and that your proper
logo will appear in the 3DS confirmation screen when customers will be paying online. In the
meantime you can focus on understanding all the APIs using Sandbox environment and make sure
that your team is ready for the work in front of them – for example by analyzing the documentation
carefully. Our services will be available for you one by one, so you don’t need to wait full 8 weeks
to start implementation – usually first work on your side starts after 2-3 weeks from the kickoff
meeting.

Test and adapt


Everyone is always eager to launch the product to final customers – that’s obvious. But it’s good to
plan an extensive testing phase that will limit the potential volume of incidents that may happen
once you’re live. A simple successful transaction done in ecommerce and brick and mortar POS is a
very good prognosis, but should not be the end of testing phase. Take into account different
scenarios and edge cases (like reversals and refunds – or even partial reversals). Take into account
that there are many players in the world of payments and that a simple transaction is actually a
connection of several backend systems (acquirer, issuer, payment network, additional vendors).
The more you test, the less surprises will be there in the end.

Knowledge and understanding is key


Issuing cards and processing transactions is unfortunately not like riding a bike – it’s easy to
forget. During the project with Verestro you’ll learn a lot about the world of payments and cards.
Make sure this knowledge is gathered on your side and distributed between team members.

Plan your MVP


Rome wasn’t built in a day. Best banks did not simply appear in a moment. Issuing cards is a vast
topic that requires a lot of iterations to make sure the basics are solid. It’s always good to start
with essentials:

Create user
Create their balance
Issue first card
Digitize the card in Apple/Google Wallet
Make first eCommerce transaction (with 3DS)
Make first POS transaction
Run ‘friends&family’ phase within your company
Then start adding features and more functionalities

If you’ll start focusing on ‘nice-to-have’ features too early in the process, you may loose sight of
more basic processes what may cause delays in the whole project.

Having all of that in mind should make your project more streamlined and effective.

Author: Adrian Durkalec


Know Your Customer – in-
house or outsourcing
From time to time, our customers ask us whether it is better to perform Know Your Customer
activities in-house or to hire a company to do it for them. In this article we would like to answer this
question.

KYC activities are very important. On-boarding your customer is actually the first process that the
customer uses, so smooth processes are critical for our future relationship with a particular
customer. If the process does not work correctly, the customer can block and all our marketing and
acquisition efforts will be useless. But how to do it right?

You can have 2 general scenarios:

Scenario 1 – build KYC in-house


You can start building this process yourself using your IT team. Actually, it is not so difficult. The
process consists of a few obligatory steps that have to be performed by user:

1. Get user data


2. Get user photo or video
3. Get pictures of user’s document or documents
4. Check sanction lists
5. Approve / decline / get into interaction

It seems to be easy �� but actually it is not so easy. There are some security and legal regulations
that need to be fulfilled. There are specific requirements of payment institutions that will have to
be fulfilled. You need to collect this knowledge, be ready to update your systems. Additionally, you
have to think of automatizing this process on your side so that the user does not wait too long for
approval of their application. From a financial perspective it sometimes can be much cheaper than
automated KYC. Let’s do a quick calculation. If you hire a person and pay 10 EUR per hour to this
person for performing KYC activities you can imagine that such a KYC employee will perform simple
consumer KYC actions (verification of data, photos etc.) for one customer during 1 minute. It means
that the cost of processing a single application is 10 EUR divided by 60 minutes = 0,16 eur per
user!!!

Additionally, if you need to perform regular scanning of sanction lists, avoiding per user costs
becomes more critical because there may be requirements that users are scanned against sanction
lists once per month… If you have 0,1 eur cost per such scanning it means that you have variable
cost of your operations. Very important disadvantage.
Advantages:

Full control over the process


Possibility of changing process in-house after product launch
Full control over costs
Possibility to avoid variable costs per user
Possibility to avoid recurring costs per user
Quicker responses to regulatory complaints as everything is in your system
No dependency on external partners

Disadvantages:

You need to spend time and energy on this process


Time consuming process
High fixed costs (team to develop and update the system)

Scenario 2 – outsource KYC


In this scenario you perform a tender and choose the best KYC provider for you. You can be
quick with this process, you will get all technology this partner has but you will have to pay per
user and maybe for some development and customizations. You will have an outsourcing company
that most likely will have to be officially registered at your regulator as you are outsourcing anti-
money laundering processes to this partner. It is definitely an easier process at the beginning of
your journey but think about dependencies and cost.

In the long term you may also encounter problems with your partner that some specific
requirements or unhappy path for your users does not work correctly. You should not think that you
can automatize 100% of your on-boarding processes and you do not need to hire anyone. You must
have some manual process, possibility to check application yourself and you must hold data
yourself for future use.

From a financial perspective – you will have to pay per user or sometimes recurring fees per
verification additionally. This may be a heavy cost for your business model. I think that this long
term dependency is the critical disadvantage and you need to be careful.

Advantages:

Quick time-to-market
Professional processes achieved quickly

Disadvantages:

High variable costs – clicks per user, monthly per user etc.
Dependency on particular vendor
Tendency to forget that you must have manual processes built together with such partner
Risk of regulatory incompliance in case you do not monitor partner correctly
Summary
It is a difficult choice. In our opinion, in the short-term, it may be better to involve a 3rd party.
However, in the long term, risk of dependencies, partner stability and variable fees seem important
and you need to carefully consider if you do not want to have those capabilities in-house. Please
also remember that while implementing 3rd party automatic solutions, you must have a manual
process ready to process unusual customers.

Our services in this area are focused on this strategy. We use both 3rd party vendors and an
internal system for managing KYC processes for ourselves and for our customers.
Reverse solicitation –
marketing & promotion of
card issuing in multiple
countries
One of the limitations in global card issuing and account opening activities is connected with
licenses and regulations for particular countries. Payment institutions have Mastercard or VISA
licenses for particular countries as this is the way Mastercard and VISA systems work. In the
European Union it is possible to get a license for the whole region but in other countries and
regions you must get a license per country.

This makes the process of card issuing difficult in today’s digital economy because you usually do
promotional and marketing activities in multiple countries. You have users from Europe, Asia,
Africa, Americas and other continents. It would not be smart to limit your payment services only to
users from particular countries.

This is a critical point and you should be discussing this point with your card issuer at the
beginning of your cooperation with them. The answer to this problem is not easy or white-black.
There are some important considerations that we present below:

Multi card issuing and multi card processing – we believe that integrations with
multiple card issuers that have licenses in multiple countries is critical for the success of
global programs. Verestro works with payment organizations in multiple countries and
solves this problem globally. In such cases, those problems disappear.
Regulatory compliance – your payment institution must check if it is legally possible to
open a payment account and provide payment cards to users from many countries. In
case of Quicko (our BIN sponsor) we are allowed to open payment instruments and
accounts to users from multiple countries assuming we fulfill AML requirements
Mastercard and VISA rules – Mastercard and VISA give licenses for particular countries.
It is impossible to get a license for all countries. There are some specific processes to get
approval for program in other countries than you have payment scheme license but it is
not clear in fact and there are some risks for every program

There are some general rules that you should follow as our partner so let us describe it:
1. You should be able to prove that the main focus of your marketing actions is in Europe if
your card issuer is based in the EU. We may ask some additional questions. Mastercard
can have a look at places where transactions are happening etc. Try to focus on Europe.
2. You should be able to provide proof that even if we are distributing cards to consumers
living abroad there is an economic interest of those people in Europe. Maybe they travel
to Europe, maybe they have employees in Europe etc.
3. If you are distributing cards to companies, make sure they have headquarters or offices
located and registered in Europe.
4. The best would be that your users have resident addresses in the European Union that
they are registering during card on-boarding. This solves all the problems.
5. We would like to be aware of your marketing activities in countries outside of Europe. It is
important that we are aware, maybe we inform local Mastercard so that they are aware.

Our intention in the long run is to solve this problem by working with multiple partners globally and
grow with licenses to other countries together with our customers. Don’t hesitate to contact us if
you want to do global card issuing business.
Interchange Fees and
Service Fees - rates and
rules
Disclaimer. This article shows in some detail the topic of Interchange Fees. It is presented in the
best way to make business decisions, but unfortunately this topic is very complex, so it does not
cover 100% of information. If you need 100% of information, please check the Mastercard and
VISA interchange manuals. Please take into account that this article is written in May 2024, we
will try to update information regularly, but make sure you get up-to-date information before
making final business decisions.

Introduction
Interchange Fees and Service fees are fees that the issuer of cards gets or pays from/to an
acquiring institution to cover cost of payment transaction or payment instrument. Those are fees
connected with using Mastercard or VISA cards that are dependent on the decision of payment
schemes and they improve or decrease P&L from card issuing activities. In Mastercard manuals
they have the following definitions:

Interchange Fee —The fee that passes between the acquirer and the issuer with respect
to the interchange of a transaction conducted at a merchant, the “purchase” part of a
“purchase with cash back” transaction or a merchandise transaction conducted at an ATM
terminal, including a chargeback, second presentment and reversal of such a transaction.
Service Fee —The fee that passes between the acquirer and the issuer with respect to
the interchange of any other type of transaction, including a manual cash disbursement
transaction, ATM transaction, PIN-based in-branch cash withdrawal, “cash-back” part of a
“purchase with cash back” transaction, refund, or payment transaction (such as
MoneySend or Gaming Payment Transaction), including a chargeback, second
presentment and reversal of such a transaction.

This is quite a complicated topic and we will not be able to cover all details in this chapter but let
us try to answer 90% of questions coming from this area. There are several factors impacting the
level of interchange. The most important are:

geography - in which the country transaction was performed. Usually Interchange is


higher for transaction performed in other countries, especially other continents
type of card - consumer vs business, debit vs credit. Consumer cards usually have lower
interchange than business cards. Debit cards usually have lower interchange than credit
cards.
type of transaction - there may be different interchange for transactions performed
online or offline, face2face POS or eCom merchant, bill payment or government,
contactless vs chip&pin etc.

Let's start with information about types of interchange from geography point of view. There are 3
important groups of transactions:

domestic transaction - transaction performed at Polish merchant, Polish acquirer with


card issued in Poland
intra-EEA transaction - transaction performed in one of EEA countries (see below), EEA
merchant, EEA acquirer, Polish or EEA card issuer
intra-European transaction - transaction performed in one of Eastern European
countries (see below), Eastern European merchant, Eastern-European acquirer, Polish or
EEA card issuer
inter-Regional transaction - transaction performed in any other country, usually
another continent, with card issued by EEA issuer

The Mastercard EEA subregion where we are located today for purposes of the application of
intra-EEA interchange fees includes the following:

the Member States of the European Union: Austria, Belgium, Bulgaria, Croatia, Czech
Republic, Cyprus, Denmark, Estonia, Finland (including Aland Islands), France (including
French Guiana, Guadeloupe, Martinique, Réunion, Saint Martin [French Part], and
Mayotte), Germany, Greece, Hungary, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Poland, Portugal (including Azores and Madeira), Romania, Slovakia,
Slovenia, Spain (including Canary Islands, Ceuta, Melilla), and Sweden
and Iceland, Liechtenstein, and Norway (including Svalbard and Jan Mayen), Andorra (for
transactions with above mentioned countries).

The Mastercard Western subregion includes the following: • All EEA subregion
countries/territories previously stated • Switzerland, Andorra, Monaco, San Marino, and Holy See
(Vatican City State), Antarctica, Greenland, Faroe Islands, Saint Barthelemy, Falkland Islands,
Guernsey, Isle of Man, Jersey, Saint Helena, Ascension and Tristan Da Cunha Helena, South Georgia
and the South Sandwich Islands

The Mastercard Eastern subregion includes the following: Albania, Armenia, Azerbaijan,
Belarus, Bosnia and Herzegovina, Georgia, Israel, Kazakhstan, Kosovo (United Nations Mission in
Kosovo), Kyrgyzstan, Macedonia, Moldova, Montenegro, Russian Federation, Serbia, Tajikistan,
Turkey, Turkmenistan, Ukraine, and Uzbekistan.

Additional complexity comes from types of cards. There is different interchange for :

debit consumer cards


credit consumer cards
business debit cards
business credit cards
Premium cards (usually credit)
etc.

Let us simplify this topic by creating a few tables with the most important Interchange Fee
examples that we recommend to use for your business calculations.

Consumer standard Mastercard debit cards for cards issued in Poland


(Polish BIN)

Domestic transaction 0.2%


some local interchange levels apply for government, bill
payment - usually max fee level is defined in those
programs.

Intra-EEA transaction 0.2%

Intra-EEA ATM Service Fee 0.5 EUR + 0.12%

Intra-European POS transaction 0.59%

Intra-European full 3DS transaction 1.19%

Intra-European ATM Service Fee 1.3 EUR + 0.2%

Inter-regional transaction POS 1.6%

Inter-regional transaction full 3DS 1.54%

Inter-regional ATM Service Fee 0.3 USD + 0.6%

Consumer Premium Mastercard debit cards for cards issued in Poland


(Polish BIN)

Domestic transaction 0.2%


some local interchange levels apply for government, bill
payment - usually max fee level is defined in those
programs.

Intra-EEA transaction 0.2%

Intra-EEA ATM Service Fee 0.5 EUR + 0.12%


Intra-European Premium POS and 3DS transaction 1.55% for Platinum

Intra-European ATM Service Fee 1.3 EUR + 0.2%

Inter-regional transaction POS and full 3DS 1.85%

Inter-regional ATM Service Fee 0.3 USD + 0.6%

Consumer Super Premium Mastercard debit cards for cards issued in


Poland (Polish BIN)

Domestic transaction 0.2%


some local interchange levels apply for government, bill
payment - usually max fee level is defined in those
programs.

Intra-EEA transaction 0.2%

Intra-EEA ATM Service Fee 0.5 EUR + 0.12%

Intra-European World Elite transaction 1.8%

Intra-European ATM Service Fee 1.3 EUR + 0.2%

Inter-regional transaction POS and full 3DS 1.98%

Inter-regional ATM Service Fee 0.3 USD + 0.6%

Consumer Mastercard credit cards for cards issued in Poland (Polish


BIN)

Domestic transaction 0.3%


some local interchange levels apply for government, bill
payment - usually max fee level is defined in those
programs.

Intra-EEA POS transaction 0.3%

Intra-EEA ATM Service Fee 0.5 EUR + 0.12%

Intra-European POS transaction 0.59% for Platinum

Intra-European full 3DS transaction 1.19%

Intra-European ATM Service Fee 1.3 EUR + 0.2%

Inter-regional transaction POS 1.1-1.6%

Inter-regional full 3DS transaction 1.54%


Inter-regional ATM Service Fee 0.3 USD + 0.6%

Business Mastercard debit cards for cards issued in Poland (Polish BIN)

Domestic transaction 0.2%


some local interchange levels apply for government,
bill payment - usually max fee level is defined in those
programs.

Intra-EEA POS transaction 1.5% (minus 0.3% if acquirer meets some criteria)

Intra-EEA full 3DS transaction 1.75% (minus 0.3% if acquirer meets some criteria)

Intra-EEA contactless transaction below EUR 25 0.8%

Intra-EEA ATM Service Fee 0.5 EUR + 0.12%

Intra-European POS chip&pin transaction 1.7% (minus 0.3% if acquirer meets some criteria)

Intra-EEA contactless transaction below EUR 25 1.15%

Intra-European full 3DS transaction 1.95% (minus 0.3% if acquirer meets some criteria)

Intra-European ATM Service Fee 1.3 EUR + 0.2%

Inter-regional transaction POS and full 3DS 2.0%


BIN Range or Separate BIN
in Card Issuing
Our customers usually ask if it makes sense to issue cards on a separate BIN fully dedicated for a
particular project or just use BIN range and share it with other partners. Let me focus on this topic
in this short article.

BIN range
There are not so many disadvantages of dedicating a BIN range for your project. In many cases this
decision will be much better. Key reasons:

The project is cheaper as we do not need to implement a new BIN with Mastercard or VISA
for you. It is a saving of around 20.000 EUR and monthly maintenance costs are cheaper
as well (500-1000 EUR monthly).
The project is faster for the same reason. It is a saving of around 3-4 months.
The setup of the BIN range is easier from an operational perspective, so you and we do
not consume more mandays for the project.

The only slight disadvantage in such an approach is that there may be a situation when this BIN
gets compromised because of some user behavior. It is a very rare situation but it could happen. If
you share the BIN with other customers, there is a risk that you will have to change the BIN and
cards for customers because of the actions of other customers. We believe that this risk is very
small - it has never happened in our history.

Separate BIN
Some people believe that if they have "own" or "dedicated" BIN, the project will be much better. In
reality it is not so. It is only more expensive and slower (see above). There is more work and some
additional risks connected with the new BIN setup. However, the advantage of a separate BIN is
the same as mentioned above - you do not share the BIN with other partners, so in case of BIN
compromise, you will know that it happens because of your actions.

I do not see any additional big differences, disadvantages or benefits of using a separate BIN.

Thanks for reading.


Guide to IBAN setup process
In this article we would like to focus on IBAN, bank accounts delivery to your customers. This topic
is raising a lot of questions and requires attention.

Let's assume that you would like to offer IBANs for your customers. If you are a fintech provider,
money transfer organization, lending company, eCom marketplace, it could make a lot of sense as
a value added product. In such a case Verestro, together with partnering payment institutions and
banks can provide you IBANs via API or inside our SDKs or white label products and your customers
will be able to transfer money to and from those bank accounts in the same way they do it in
normal mobile or internet banking.

But what happens in the background? How does it work?

There are a few dimensions that we need to remember about once enabling the IBAN product -
technology, money movement, money holding, liquidity management etc.

Technology
From a technology perspective it is not very difficult. You just go to section IBAN management in
our Developer Zone and can find APIs. Please remember that you must create a user first in our
database, perform KYC in majority of cases, create a balance or account for this user and once it is
done you will use this IBAN API to create an account number (IBAN) for this payment account.

In the background, during project setup and operations, Verestro and our partnering payment
institutions create for you a set of IBANs from one or more banks that will be used in case you
request IBANs or transfers via API. Once transactions come to this IBAN, technically you are
receiving information from our system that the balance of the account changed and you can
display this information to the user.

Money Movement
By Money Movement we mean a process of transferring real money from sender to receiver.
Because we are using various payment institutions and banks behind our system, it is worth
discussing. There are the following steps in this transaction:

1. Sender sends money to IBAN of your user generated at Verestro platform


2. Our partnering payment institution or bank receives information about incoming transfer
to this IBAN
3. Verestro platform informs you about the incoming transfer and optionally initiates
movement of money to another bank which acts as settlement bank for your transactions.
This happens in case IBAN is generated in another payment institution than Settlement
Bank
4. Money gets available on user or your account or for settlements of card transactions at
the moment it arrives at Settlement Bank (usually you do not experience any problems as
it is at D+1 time)

Money Holding
In all cases money is held by banks cooperating with Verestro so they are secure in the same way
as any other banking account in those banks. We cooperate only with strong and reliable banks in
various countries (usually based in Poland).

Liquidity Management
In some cases once you are receiving and sending money from and to IBANs, in order to avoid
delays of money transfers between various payment institutions and banks, it is necessary to place
and manage additional liquidity benefits so that your users could send money faster. We will
inform you about such situations during the project depending on the requirements and use case
we are going to implement together.

Thank you for reading.


IBANs, cards, balances - how
to manage all of this?
Once you are starting a payment account and/or card issuing project you need to learn key
definitions and relations between those various parameters.

Balance ID - this is a real "account" in the Verestro system. This number is connected with User ID
and means that the user has an account and balance in our system. The user can keep money on
this Balance ID. Of course, one user can have multiple balances but a single balance can belong to
one user only

IBAN - this number is often mixed with Balance ID. IBAN is a number through which the user can
receive money to his balance via wire transfer. IBAN is not a balance ID. Generally it does not make
sense to have more than one IBAN for one balance. Normally you issue one IBAN for one balance.
Usually a user can have more IBANs and balances if he wants to keep money on separate accounts,
in various currencies etc.

Card number - easier to understand, just a card number issued to a particular balance ID (not to
IBAN!). A user can have multiple cards connected to one balance ID.

Once preparing to project with Verestro, please learn the above definitions. More info here:
https://developer.verestro.com/shelves/card-issuing-ibans
Issuing cards in various
currencies
Verestro and its partners can issue cards in multiply currencies. Depending on the currency it is
easier or more difficult but it is possible to issue cards in multiply currencies. Let me explain how to
do it in this article.

Firstly, let's discuss that to issuing cards in particular currency (let's say CZK) means that user has
an account in CZK and when he is paying 100 CZK his account gets debited with 100 CZK. To
achieve this situation normally the card issuer needs to implement Settlement Service with
Mastercard or VISA in CZK. This means that card issuer will have to send 100 CZK to Mastercard
after the transaction so that Mastercard could transfer it to acquiring institution and later to
merchant. Once this Settlement Service is enabled everything works well but the problem exists if
issuer does not have Settlement Service in particular currency or sometimes such Settlement
Service does not even exist and issuer must settle money in USD or EUR. Sometimes it is not worth
spending money and time on new Settlement Service implementation as it can cost 25-40k euros.

In such situation we can implement Internal Settlement with partner in particular currency. It
means that users will keep money in CZK, users will be charged 100 CZK if they pay 100 CZK but
all money transfers between Verestro payment institutions and our partners will be happening in
EUR. There will be some FX risks connected with this approach but they can be covered through a
bit higher fees for users.

There is only one exception to this rule - it is necessary that we can hold money in this new
currency in the banks where we hold accounts. It is necessary that accounts are stored in this
particular currency to avoid difficult fluctuations.

Ask us for Internal Settlement if you are interested in card issuing in multiply currencies.
What steps should be taken
to start a card issuing
project with Verestro outside
the European Economic
Area?
At Verestro, we are focused on simplifying global fintech space by building a multifunctional, multi-
BIN-sponsor, multi-processor, multi-acquiring, multi-bank platform. Our final target is to offer
payment and financial services globally in any country in the world. Today we are offering card
management, tokenization and payments on 5 continents. We store above 5 mln cards and tokens.
In the group we process over 2 bln USD in payment transactions annually.

If you are interested in issuing cards outside of Europe, we can start a project immediately.
Normally such a process works in the following way:

1. You contact us and we talk about your plans.

2. You can start integration with our Sandbox immediately using the tech documentation and APIs
released in our Developer Zone https://developer.verestro.com/.

3. We sign a contract to cover the services.

4. We search for BIN sponsors relevant for markets where you operate unless we have them
already integrated and commercially ready.

5. You can issue cards, enable payouts to cards or enable other payments once you finalize your
technical integration and we are ready with the chosen BIN sponsor on the particular market.

6. We take care of all operations, settlements. You take care of your go-to-market strategy,
frontend, marketing, pricing, etc.
The big advantage of such an approach is that your platform is not dependent on a single BIN
sponsor, you can work with multiple partners. You can also migrate the program easily to your own
BINs once it grows and you become a direct Principal Member of Mastercard or VISA.

You might also like