What are the technical components required to issue banking cards in Morocco?

Issuing banking cards in Morocco requires four main components: a card management system (CMS), a real-time authorization processor, an HSM (Hardware Security Module) for cryptographic management, and a PCI-DSS compliant platform. The entire system must be connected to the Visa and/or Mastercard networks through the Centre Monetique Interbancaire (CMI) or directly.

What is the difference between a card issuer and a card processor in Morocco?

The issuer is the institution licensed by Bank Al-Maghrib that holds the regulatory and financial responsibility for each card. The processor is the technical platform that handles real-time transactions: authorizations, clearing, limit management and fraud detection. An issuer can internalize processing or delegate it to a certified third party.

How much does the technical infrastructure cost to issue cards in Morocco?

Building your own processing infrastructure costs between 5 and 15 million MAD, not including PCI-DSS certification costs and network connection fees. By partnering with a BaaS provider like ChariBaaS, the initial investment is reduced to API integration and program fees, allowing you to launch a card program for a fraction of that cost.

What is tokenization and why is it important for card issuing?

Tokenization replaces the real card number (PAN) with a unique token during mobile payments (Apple Pay, Google Pay) and recurring online transactions. It significantly reduces fraud risk because the token has no value outside its usage context. Any modern card issuing program must support tokenization.

Card Issuing in Morocco: Technical Guide 2026

Introduction: Card issuing is a full-scale engineering system

Issuing a banking card is not just about printing a plastic with a logo. Behind every Visa or Mastercard issued in Morocco lies a complex technical infrastructure: real-time authorization systems, cryptographic modules, security protocols, connections to international networks and a strict regulatory framework.

This guide is aimed at technical teams — CTOs, system architects, product managers — who want to understand how card issuing works in Morocco, what components are needed, and how a BaaS partner like ChariBaaS can simplify this process.

If you are looking for a business overview of white-label cards instead, see our article: White-Label Banking Cards in Morocco.

Architecture of a card issuing system

A card issuing system breaks down into several technical layers, each playing a specific role in the card lifecycle and transaction processing.

The Card Management System (CMS)

The CMS is the heart of the system. It manages the complete lifecycle of each card: creation, activation, suspension, replacement, renewal and closure. The CMS stores card data (PAN, expiration date, status), program rules and each cardholder's parameters.

The main functions of the CMS include:

Lifecycle management: creation of physical and virtual cards, activation, temporary blocking, replacement, cancellation
Rule configuration: transaction limits (daily, weekly, monthly), geographic restrictions, merchant category code (MCC) restrictions
Cardholder management: linking the card to the payment account and cardholder identity
Reporting: data extraction for compliance, business intelligence and fraud analysis

The Authorization Engine

When a cardholder presents their card at a merchant or online, an authorization request is sent in real time to the issuer. The authorization engine is the component that receives this request, evaluates it and returns a response (approval or decline) within milliseconds.

The authorization engine performs the following checks on each transaction:

Card status verification: Is the card active? Not expired? Not blocked?
Balance verification: Does the associated payment account have sufficient funds?
Limit checks: Does the transaction comply with defined limits (single amount, daily cumulative, number of transactions)?
MCC restrictions: Is the merchant category allowed by the program rules?
Fraud controls: Are fraud detection rules (velocity, geolocation, unusual behavior) satisfied?
3D Secure authentication: For online transactions, the processor manages the 3DS flow (Verified by Visa / Mastercard SecureCode)

Response time is critical: Visa and Mastercard networks impose a maximum response time of 2 to 3 seconds. Beyond that, the transaction is automatically declined (timeout).

The Cryptographic Module (HSM)

The HSM (Hardware Security Module) is a dedicated hardware device for managing cryptographic keys. It is essential for:

Card key generation: each card has unique cryptographic keys (CVV, iCVV, dCVV) generated and stored in the HSM
PIN verification: the PIN is verified by comparing the encrypted PIN received with the stored value, without ever exposing the PIN in plaintext
Sensitive data encryption: PANs and other sensitive data are encrypted at rest and in transit using keys managed by the HSM
Tokenization: generation and management of tokens for mobile and online payments

HSMs used in the card industry must be certified FIPS 140-2 Level 3 or higher, and comply with PCI PTS (Pin Transaction Security) requirements.

The Network Gateway

The network gateway is the connection point between the issuer's system and the payment networks (Visa, Mastercard). In Morocco, this connection can go through the Centre Monetique Interbancaire (CMI), which acts as an intermediary for domestic transactions, or be established directly with the networks for international transactions.

The network gateway handles:

ISO 8583 messages: the standard protocol used for card transactions (authorizations, cancellations, reversals)
Routing: directing transactions to the correct network based on the BIN
Clearing and settlement: exchanging clearing files with the networks for financial settlement of transactions

End-to-end transaction flow

To fully understand the infrastructure, let us follow the complete path of a card transaction, from the moment the cardholder presents their card to the final settlement.

Phase 1: Authorization (real time)

The cardholder presents their card at a merchant (chip, NFC or online payment)
The merchant's payment terminal sends an authorization request to its acquirer (the merchant's bank)
The acquirer transmits the request to the network (Visa or Mastercard) via the ISO 8583 protocol
The network identifies the issuer through the BIN and routes the request to the issuer's processor
The authorization engine executes the checks (status, balance, limits, fraud)
The processor returns a response (code 00 = approved, or a decline code)
The response flows back up the chain: network, acquirer, terminal, and the merchant sees "Transaction approved"

This entire flow takes place in under 2 seconds under normal conditions.

Phase 2: Clearing

At the end of the day, authorized transactions are consolidated into clearing files exchanged between the issuer, the network and the acquirer. It is during this phase that exact amounts are confirmed (the final amount may differ slightly from the authorization, for example for restaurant tips or foreign currency transactions).

Phase 3: Settlement

Settlement is the actual transfer of funds. The issuer debits the cardholder's account and transfers the funds to the network, which redistributes them to the merchant's acquirer. This process typically occurs on D+1 or D+2.

PCI-DSS certification: A non-negotiable requirement

Any entity that stores, processes or transmits card data must comply with the PCI-DSS (Payment Card Industry Data Security Standard). For a card issuer, this certification is non-negotiable.

The 12 PCI-DSS requirements

The PCI-DSS standard comprises 12 requirements grouped into 6 objectives:

Install and maintain a firewall to protect cardholder data
Do not use vendor-supplied defaults for system passwords and security parameters
Protect stored cardholder data (encryption, masking)
Encrypt transmission of cardholder data across open networks
Use and update antivirus software
Develop and maintain secure systems and applications
Restrict access to cardholder data on a need-to-know basis
Assign a unique ID to each person with computer access
Restrict physical access to cardholder data
Track and monitor all access to network resources and cardholder data
Regularly test security systems and processes
Maintain a policy that addresses information security

Compliance levels

For card issuers, the highest compliance level (Level 1) is generally required. This involves an annual on-site audit by a QSA (Qualified Security Assessor) certified by the PCI SSC, as well as quarterly penetration tests by an ASV (Approved Scanning Vendor).

The cost of obtaining and maintaining PCI-DSS Level 1 certification is significant: between 500,000 and 2,000,000 MAD per year, including the audit, testing, security infrastructure and dedicated human resources.

Tokenization: Securing modern payments

Tokenization has become a pillar of modern card issuing. It is essential for supporting mobile payments (Apple Pay, Google Pay, Samsung Pay) and recurring online transactions.

How tokenization works

The principle is simple: the real card number (PAN) is replaced by a unique token, generated by the Token Service Provider (TSP) of the payment network. This token is tied to a specific context: a device, a merchant or a payment channel.

When a cardholder adds their card to Apple Pay, for example:

The application sends the card data to the Visa or Mastercard TSP
The TSP contacts the issuer to verify and authorize tokenization
The issuer approves and the TSP generates a token (DPAN — Device PAN)
The token is stored in the phone's Secure Element
During a payment, it is the token that is transmitted, never the real PAN

Tokenization benefits for the issuer

Fraud reduction: a stolen token is not usable outside its context
Automatic updates: when a card is renewed, tokens are updated automatically, without the cardholder needing to re-register their card
Better user experience: mobile payments are faster and smoother
Simplified PCI compliance: merchants using tokens do not need to store PANs

Security protocols: 3D Secure and EMV

3D Secure 2 (3DS2)

The 3D Secure protocol is the authentication standard for online payments. Its version 2 (3DS2), now mandatory in Morocco for e-commerce transactions, significantly improves the user experience compared to the first version.

In 3DS2, the issuer receives a set of contextual data about the transaction (device used, IP address, cardholder history) and can decide to authenticate the cardholder "frictionless" (without interaction) or request strong authentication (SMS OTP, biometrics).

The issuer must deploy an ACS (Access Control Server) to manage the 3DS2 flow. This ACS receives authentication requests, evaluates risk, and returns the decision to the merchant via the network's Directory Server.

EMV and chip cards

The EMV standard (Europay, Mastercard, Visa) governs chip card and contactless (NFC) transactions. Each EMV card contains a chip that generates a unique cryptogram for each transaction, making card cloning virtually impossible.

For an issuer, EMV compliance involves:

Chip personalization: loading cryptographic keys, cardholder data and risk parameters into the chip during manufacturing
EMV script management: the issuer can send commands to the chip via scripts (counter updates, PIN changes, card blocking)
Contactless transaction support: configuring NFC parameters (CVM limit, floor limit)

API integration: How ChariBaaS simplifies card issuing

One of the main advantages of the BaaS model is transforming this technical complexity into simple, well-documented APIs. Rather than building and certifying your own infrastructure, you integrate your BaaS partner's APIs.

Main endpoints

A card issuing system exposed via API typically offers the following endpoints:

POST /cards: create a new card (physical or virtual) for a given cardholder
GET /cards/{id}: retrieve card details (status, type, expiration date)
PATCH /cards/{id}: modify card parameters (limits, status, restrictions)
POST /cards/{id}/activate: activate a physical card after receipt
POST /cards/{id}/freeze: temporarily block a card
POST /cards/{id}/unfreeze: unblock a card
GET /cards/{id}/transactions: list a card's transactions
POST /cards/{id}/pin/reset: reset a card's PIN
GET /cards/{id}/sensitive-data: retrieve sensitive data (PAN, CVV) for secure display in the application

Webhooks and events

In addition to APIs, a card issuing system sends real-time notifications via webhooks for each significant event:

card.created: a card has been created
card.activated: a card has been activated
card.frozen / card.unfrozen: blocking or unblocking
transaction.authorized: a transaction has been authorized
transaction.declined: a transaction has been declined
transaction.settled: a transaction has been settled
transaction.reversed: a transaction has been reversed

These webhooks allow your application to react in real time: push notification to the cardholder, update the displayed balance, trigger security alerts.

Integration security

Access to card issuing APIs is protected by multiple security layers:

OAuth 2.0 authentication: each API call is authenticated via a bearer token
TLS 1.3 encryption: all communications are encrypted in transit
IP Whitelisting: only authorized IP addresses can call the APIs
Tokenized sensitive data: PANs and CVVs are never transmitted in plaintext in API responses; they are accessible only through a dedicated endpoint with a single-use token

The role of CMI in the Moroccan ecosystem

The Centre Monetique Interbancaire (CMI) is a central player in Morocco's card payment ecosystem. Created by Moroccan banks, it plays a dual role: domestic acquirer and payment switch.

CMI as a switch

The CMI routes domestic transactions between Moroccan issuers and acquirers. When a cardholder with a card issued in Morocco pays at a Moroccan merchant, the transaction may pass through the CMI switch rather than international networks. This reduces processing costs and delays.

Implications for an issuer

A card issuer in Morocco must be connected to the CMI (directly or through its processor) in order to:

Process domestic transactions efficiently
Participate in the interbank clearing system
Comply with local routing rules defined by Bank Al-Maghrib

Build vs. buy: The economic calculation

Technical teams evaluating a card issuing program face a fundamental choice: build their own infrastructure or rely on a BaaS partner.

Building in-house

Building your own issuing infrastructure involves:

Obtaining a license as a payment institution from Bank Al-Maghrib (6 to 18 months)
Obtaining a BIN from Visa or Mastercard (member certification process)
Deploying a CMS and authorization processor (purchase or license specialized software)
Installing and certifying HSMs (200,000 to 500,000 MAD per module)
Obtaining PCI-DSS Level 1 certification (500,000 to 2,000,000 MAD/year)
Connecting to the CMI and payment networks
Recruiting a specialized team (payment engineers, compliance officers, operations)

The total setup cost is estimated at between 10 and 20 million MAD, with a timeline of 12 to 24 months before the first launch.

Leveraging a BaaS partner

By partnering with a provider like ChariBaaS, you access this entire infrastructure via APIs, without a massive upfront investment:

No license required: ChariBaaS is already licensed by Bank Al-Maghrib
No BIN to obtain: the BIN is the partner's (BIN sponsorship)
No PCI certification: the infrastructure is already certified
Fast integration: 8 to 16 weeks to launch
Proportional cost: fees per card issued and per transaction, rather than a fixed investment

This model is particularly suited for fintechs, startups and businesses that want to validate a use case before investing heavily.

Physical card: The manufacturing and personalization process

Issuing physical cards involves a significant logistical dimension that technical teams must plan for.

Manufacturing

Physical cards are manufactured by printers certified by Visa and Mastercard. Manufacturing includes:

Design printing: visuals are printed in high quality on PVC, PET or metal substrates
Chip encapsulation: the EMV chip is integrated into the substrate and connected to electrical contacts
NFC antenna integration: for contactless cards, an antenna is embedded in the card body
Quality control: each batch is tested to verify chip readability, NFC functionality and print quality

Electrical personalization

Electrical personalization involves loading the cardholder's data and cryptographic keys into the card's chip. This step takes place in a certified secure environment:

EMV profile loading: risk parameters, limits, application ID
Cryptographic key injection: session keys, PIN encryption keys, authentication keys
Cardholder data writing: PAN, expiration date, cardholder name

Graphic personalization

Graphic personalization includes:

PAN engraving or printing: the card number can be embossed, indent-printed or flat-printed
Cardholder name and expiration date printing
CVV application on the back of the card

Fulfilment and shipping

Once personalized, the card is placed in a secure envelope with an accompanying letter containing activation instructions. Shipping is done via a secure carrier, with tracking and proof of delivery.

Fraud management: Tools available to the issuer

Fraud is the number one risk for a card issuer. A robust fraud management program combines static rules, scoring models and real-time monitoring tools.

Detection rules

The most common detection rules include:

Velocity: number of transactions within a time window (e.g., more than 5 transactions in 10 minutes)
Unusual amount: transaction significantly higher than the cardholder's average amount
Geolocation: transaction in a different country from the last transaction, within a timeframe incompatible with physical travel
High-risk MCC: certain merchant categories carry a higher fraud risk
Multiple attempts: several declined payment attempts in a short time

Risk scoring

Modern systems assign a risk score to each transaction by combining static rules with machine learning models trained on transaction history. This score determines whether the transaction is approved, declined or subject to additional verification.

Monitoring and alerts

A real-time monitoring dashboard allows the operations team to track fraud rates, suspicious patterns and alerts. Automatic alert thresholds trigger notifications when indicators exceed normal levels.

How ChariBaaS can help

ChariBaaS (Chari Money SA) is a payment institution licensed by Bank Al-Maghrib that offers a complete card issuing infrastructure accessible via API.

ChariBaaS technical infrastructure

Authorization processor: real-time processing with 99.99% uptime
Complete CMS: lifecycle management for physical and virtual cards
Certified HSM: cryptographic management compliant with PCI PTS standards
PCI-DSS Level 1 compliance: infrastructure audited and certified annually
CMI and network connection: direct integration with CMI, Visa and Mastercard
Fraud management: configurable rules and real-time risk scoring
3D Secure 2: integrated ACS for online transaction authentication
Tokenization: Apple Pay, Google Pay and merchant tokenization support

Who is this for?

This service is designed for fintechs, businesses and platforms that want to integrate card issuing into their product without building their own infrastructure.

To learn more, visit our card issuing services page or contact our team to discuss your project.

Conclusion

Card issuing is a demanding engineering domain that combines security, performance, compliance and reliability. Every component — from the HSM to the authorization processor, from the CMS to the network gateway — must function flawlessly to guarantee a smooth and secure payment experience.

In Morocco, the regulatory framework and technical infrastructure are in place. Payment institutions licensed by Bank Al-Maghrib like ChariBaaS already offer card issuing solutions accessible via API, enabling any business to launch its own card program without a massive upfront investment.

The choice between building and buying depends on your scale, ambition and resources. But in most cases, the BaaS model offers the best cost-to-time ratio for a fast and controlled launch.

For further reading, see our related resources: