Article

You can find more knowledge about products on this site.

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

image-1711799598153.png

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.

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.

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 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.

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.

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:

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? 

2. COSTS - Obvious point.

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

    • 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.

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

Name Country Revenue Share Costs Functionality & Service Security & 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 assessment Make your own assessment Make your own assessment Make your own 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.

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.

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:

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 :

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:

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:

Problematic areas

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

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. 

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 transactions per year

·       Less than 1 million other transactions per year

·       Complete an annual Self-Assessment Questionnaire (SAQ)

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

3

·       20 000 – 1 million transactions per year

·       Complete an annual Self-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. 

image-1713429427331.jpg


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:

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

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

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.

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. 

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:

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.

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

Debit cards

This is the biggest group of cards in the world:

Credit cards

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:

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

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 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. 

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?

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.

What are the legal and payment scheme rules for launching a prepaid card program without KYC?

Recently we have been asked the question: “What are the options for a merchant or cafeteria to launch a card program based on prepaid cards (such as lunch cards and gift cards) that doesn't require a KYC process?”

There are a lot of misleading pieces of data regarding prepaid cards and gift cards. Those issues are mainly caused by differences between the legal environment and Mastercard or VISA rules. In this article we would like to go deeper into this topic and explain what is possible and what is not possible.

Key regulatory and scheme requirements for prepaid card programs

Let’s start with key rules:

1.  PSD2 (legal environment in Europe) and AML law say that payment institutions have to know their customers so full KYC must apply. Sometimes, depending on the country, some limited KYC rules are possible in case a payment institution issues a payment instrument with payment or transaction limits i.e. non-reloadable gift cards. We work in compliance with the Polish law which states that it is possible to issue anonymous cards only in case:

a.  Value of monthly transactions is limited to 150 EUR

b.  Value of such card is limited to 150 EUR

c.  Only POS and eCommerce transactions are allowed

2. Mastercard and VISA rules claim that in case of specific non-reloadable prepaid cards it is possible to issue anonymous cards. It requires special approval for the program.

3. In some specific use cases (expense management, lunch cards) it is possible to perform KYB of the company selling prepaid cards only. In such a case money on account must belong to the company and the company can issue such cards with limited KYC to its employees or users.

Implementing reloadable and non-reloadable gift cards

Taking the above rules into account, we can imagine the following scenarios: 

Scenario 1 – non-reloadable gift cards with limits up to 150 EUR with limited acceptance

It is possible to issue cards for such programs after approval of the payment scheme.

Scenario 2 – reloadable gift cards for the company and its business expenses

It is possible to sell gift cards connected to the business account of the company (after KYB) assuming payments are connected with expenses or specific use cases of this company. 

Please contact us if you want to issue similar programs with simplified KYC rules. We will advise on the best scenario and try to find ways to quickly launch a prepaid card program that meets your business needs.

 

Card Program – in-house or via BaaS?

When launching a new card program, you must decide whether to do it yourself or hire a BIN sponsor or processor and outsource the program to an external entity. This article will address this question, arguing that flexibility and speed-to-market are the most important decision factors.

Let’s start with the definition of a card program and its various parts. Building a new card program requires making decisions in the following areas:

Building a new card program is almost like building a bank. You need a lot of competences, technology pieces, licenses etc. Obviously, it takes both money and time. It is impossible to run your own card program without 10-20 people being engaged in daily operations, scheme and regulatory compliance, not even talking about technology.

On the other hand, you have the possibility to start a program with a BIN Sponsor or Banking-as-a-Service (BaaS) partner who will be responsible for all those actions. In this case, you will have quick time-to-market but you will have to pay variable fees for those actions.

The answer to which is better is not actually that difficult. In our opinion, the best scenario is to choose a partner with whom you can quickly start (BIN sponsor) and convert your program to a direct license once it grows. This means you can start issuing cards in 3-4 months without high entry costs. You can start building a portfolio and earning first revenue. Once your portfolio reaches around 500,000 cards, it will be worth investing in your own licenses.

Launching card issuing quickly and cost-effectively is critical. While an in-house solution would cost €2.4 million over two years, leveraging Card as a Service (CaaS) / BaaS dramatically reduces both time and initial investment to just €0.2 million, with deployment in 3-4 months. This is the clear choice for agility and financial prudence.

Once you start a project with us, we ensure the flexibility of your development in the long run. We can act as a BIN sponsor and once you are willing to have your own licenses we can either help you in getting a Mastercard or Visa affiliate license or transfer your cards to your own principal membership. Once the cards are issued under your own license, we will act as an issuing processor, and you will only cover technology-related costs. This approach is flexible because it gives you the option to issue cards not only on your own license, but also to use our BIN sponsorship for various projects. This approach offers the best entry costs, the quickest time to market, and highly flexible development scenarios.

If you need more information about our work process, please contact us.

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:

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.