Executive Summary
- A bank-led programme can preserve a software role if the bank actually issues the cards, accepts customers, owes the balances and controls payment execution. A contract describing the fintech as a programme manager does not decide its legal status. The Saudi Central Bank (SAMA) lists instrument issuance, payment execution, e-money and payment accounts as regulated services, while excluding technical services. (Law of Payments and Payment Services, Royal Decree No. M/26 of 22/3/1443H, art. 4; Implementing Regulations, Circular No. 000044093096 of 13 June 2023, arts. 6–7, 48.)
- Select Al Rajhi Banking and Investment Corporation as the proposed pilot issuer, conditional on its acceptance of the specified product and contracts. Each Saudi company should hold its own bank account and corporate prepaid master record. The fintech should never receive the prepaid money. Al Rajhi publicly offers corporate prepaid cards; the proposed integration and allocation of responsibilities require a separate agreement. (Al Rajhi Bank, Corporate Prepaid Mada/Visa Card; Corporate Cards Terms and Conditions, definitions and cl. 2.)
- Independent authority to issue cards, approve payment customers, promise redemption or operate customer payment accounts would undermine the software classification. Bank agency requires its own approval route. Ordinary outsourcing cannot substitute for approved agent banking. (Implementing Regulations, arts. 6, 24, 27; Rules on Outsourcing, para. 9; Regulation of Agent Banking, arts. 4, 19.)
- An independently operated Saudi group issuer should seek the permission matching its liabilities and services. An electronic money institution (EMI) is the relevant model if it owes redeemable stored value. Major EMI status still carries default customer balance and monthly transaction limits of SAR 100,000, which SAMA may increase. (Implementing Regulations, arts. 1, 6, 43(5)–(6), 44.)
- Corporate prepaid rules require employee subrecords and restrict their multiplication. The pilot should use one approved card instrument per employee, with company budgets inside the bank-approved record structure. Credit rules become relevant when the issuer provides credit, including a charge card repayable in full each month. (Regulatory Rules for Prepaid Payment Services in the Kingdom of Saudi Arabia, Circular No. BCT/15631 of 2 May 2012, para. 2.4.2; Rules of Issuance and Operation of Credit Cards, Circular No. 106911157 of 19 June 2025, art. 1.)
- Foreign issuance does not remove Saudi territorial restrictions when the programme markets to Saudi companies or residents. The launch should remain conditional on separate Egyptian legal and licence clearance. The pilot should keep Saudi funding and production payment operations in Saudi Arabia. (Implementing Regulations, art. 4.)
The payment services behind the corporate card
The proposed product performs several legally distinct functions. The issuer agrees with the Saudi company to provide the payment instrument. The account provider records the company's funds and owes the balance. The payment service provider executes funded card transactions. If a non-bank accepts money in exchange for electronically stored value accepted by third parties, its liability also requires an e-money analysis. Saudi implementing regulations list instrument issuance, payment execution, e-money issuance and payment accounts separately. A card issuing API can implement those functions without determining who legally provides them. Here, API means the software interface through which systems exchange requests. (Implementing Regulations, arts. 1, 6(3), 6(5), 6(8), 6(11).)
Employee budgets, expense approvals and receipt matching can remain software functions. A budget is an employer's spending mandate where it creates no separate redeemable balance owed by the fintech. Merchant-category controls and card requests can also operate within the issuer's approved rules. The fintech cannot rely on the technical-services exclusion for an independently supplied payment service. Absence of fund possession alone does not resolve that question: payment initiation and account-information services also appear in the regulated list. (Implementing Regulations, arts. 6(9)–(10), 7(9).)
Merchant acquiring belongs on the merchant side of the transaction. The merchant's acquirer contracts to accept and process payments for that merchant. Providing employee cards, expense controls or reconciliation does not, on the proposed facts, make the fintech an acquirer. A later merchant-acceptance product, merchant settlement account or aggregation service would require a separate perimeter assessment. The intragroup exclusion does not extend to ordinary purchases from unrelated merchants merely because the cardholder's employer belongs to an Egyptian group. (Implementing Regulations, arts. 1, 6(6)–(7), 7(13).)
The legal issuer, network sponsor and software supplier must remain identifiable. A scheme member supplies the network relationship and relevant bank identification number (BIN) arrangements; an issuer supplies the cardholder undertaking. Those roles can sit with the same bank. A processor performs technical authorization or clearing tasks under its principal's instructions. A programme manager coordinates the product only within its lawful mandate. Scheme membership and BIN sponsorship confer contractual network access, without transferring the member's Saudi statutory permission to the Egyptian company. (Law of Payments and Payment Services, art. 4; Implementing Regulations, arts. 6, 24, 27; Visa Core Rules, rules 1.9.8.5–1.9.8.6.)
A Saudi bank as the proposed issuer
The first product should be a bank-issued corporate prepaid card programme for Saudi legal entities with established banking relationships. Select Al Rajhi Banking and Investment Corporation as the proposed issuing bank. Its public product materials identify a corporate prepaid Mada/Visa offering. Selection here means a proposed contractual counterparty, without representing an existing partnership or an agreed white-label API. The bank should remain the legal issuer, account provider and network-facing principal. (Al Rajhi Bank, Corporate Prepaid Mada/Visa Card; Corporate Cards Terms and Conditions, definitions; SAMA, List of Domestic Systemically Important Banks for 2026.)
Each Saudi company should contract directly with the bank under Arabic corporate prepaid terms and an agreed product schedule. The company should open or maintain its own corporate SAR bank account. A separate corporate prepaid master record should identify that company as the contracting entity. Transfers should originate only from its verified Saudi bank account. The bank should maintain the corresponding employee subrecords; the fintech should have no pooled collection account, account title, withdrawal right or beneficial claim to those funds. This implements the corporate master-record structure required by the prepaid rules. (Prepaid Payment Services Rules, paras. 2.4.2, 2.8.4–2.8.7.)
The employer should own the programme funds, while employees act as authorized card users. An employee's displayed budget should record the employer's mandate within the master balance. It should create no payment account or redemption promise from the fintech to that employee. The bank's terms should identify the party entitled to unused balances and require repayment to the verified corporate funding account, subject to lawful holds. The employer should bear corporate programme charges rather than pass them to employees. (Prepaid Payment Services Rules, paras. 2.4.2, 2.8.2–2.8.3.)
The proposed Saudi technology subsidiary, Saudi TechCo, should sign a separate software agreement with each employer. That agreement should cover budgets, approvals, receipts and reconciliation. A bank-to-TechCo contract should govern the technical integration. The Egyptian parent should provide intellectual property and development support within a defined subcontract. Initial development should use synthetic or genuinely anonymized data, with no Egyptian access to live payment records or card credentials. The bank should classify the initial development subcontract as well as later operational services. Where either arrangement outsources a bank function abroad, prior written SAMA non-objection is required even without live-data access. (Rules on Outsourcing, paras. 18–20, 24–26, 42; Personal Data Protection Law, arts. 8, 29.)
The bank should authorize transactions against available funds, record holds, reconcile clearing and settle through its network arrangements. The fintech may display authorization results and reconciliation entries, but its ledger should remain subordinate to the bank's record. Merchant refunds should return through the issuer and credit the correct corporate master balance. Any employee allocation should transfer from that master record without double counting. A software adjustment must never itself create bank money or discharge the bank's debt. The prepaid agreement should allocate unmatched refunds, late presentment and reversals without granting a borrowing facility. (Implementing Regulations, art. 6(3); Prepaid Payment Services Rules, paras. 1.2.1, 2.4.2, 2.8.2.)
The issuer should decide payment disputes, conduct chargeback processes and answer complaints. Saudi TechCo may transmit evidence and provide a support interface, but the company must retain direct access to the bank. Software termination must leave cards, balances, statements and statutory complaint channels accessible through the issuer. This bank-account model differs from non-bank e-money safeguarding: the customer's claim lies against the bank under the account and prepaid terms. It should not be described as a fintech trust account or an EMI safeguarding arrangement. (Prepaid Payment Services Rules, paras. 2.8.6, 2.10; Rules on Outsourcing, paras. 8, 22; Implementing Regulations, arts. 48, 93–94.)
Control that exceeds a software mandate
The fintech cannot preserve an independent right to set all card terms and still rely on the bank's name as issuer. Bank-approved product proposals, negotiated commercial fees and a branded interface can fit a supplier role. The bank must adopt the operative card terms, remain identified in advertising and retain responsibility for the payment undertaking. The prepaid rules expressly require the issuer's identity and contact information in programme advertising. Branding must not tell customers that the Egyptian fintech holds their money or guarantees redemption. (Prepaid Payment Services Rules, paras. 2.8.4, 2.9.2–2.9.3.)
Customer acceptance requires particular care. The bank should own the eligibility policy, verify the Saudi company and beneficial owners, and make the final acceptance decision. Technical collection of documents should follow a documented bank-controlled process. If Saudi TechCo actually opens accounts, solicits card applications or performs other bank-agent activities, final bank approval alone does not convert that role into ordinary outsourcing. Paragraph 9 of the outsourcing rules prohibits outsourcing the banking services listed in Article 19 of the agent-banking regulation. Approved bank agency is a separate possible structure. (Rules on Outsourcing, para. 9; Regulation of Agent Banking, arts. 4, 19.)
Saudi TechCo should therefore supply the pilot's technical workflow while the bank performs the customer-facing banking functions. Any proposed expansion into agency should require a fresh contract, the applicable eligibility review and SAMA's approval. A non-bank PSP sponsorship also has a distinct agent regime: its agent requires SAMA's non-objection and cannot issue e-money itself. Distribution or redemption under the principal's authority does not make the agent an independent e-money issuer. (Regulation of Agent Banking, arts. 4–5; Implementing Regulations, arts. 24–25.)
Employers should select budgets and tighten spending limits within issuer-approved ranges. The bank should control hard limits, identity-linked card records, fraud blocks, exceptions and final authorization. A card issuing API request should cause the issuer's approved process to create the instrument. The fintech should have no unilateral ability to bypass those controls, reactivate a bank-blocked account or promise execution after an issuer refusal. Technical automation can execute a bank's decision rules; independent payment discretion would change the underlying service. (Implementing Regulations, arts. 6–7; Prepaid Payment Services Rules, para. 1.2.1.)
Saudi TechCo can charge a separate software subscription. Card charges should appear in the bank's terms and be collected by the bank. Any interchange or service-revenue share should arise under the bank-TechCo commercial agreement and be paid from the bank's own earned revenue. The fintech should obtain no lien over prepaid balances and no right to debit them for its subscription. Revenue sharing alone does not establish issuance; the accompanying contractual undertaking and operational powers determine the relevant service. (Implementing Regulations, arts. 1, 6–7; Prepaid Payment Services Rules, paras. 2.8.3–2.8.4.)
The strongest contrary view treats the bank as a nominal issuer and the fintech as the actual payment provider. That view becomes persuasive if the fintech acquires customers in its own name, determines acceptance, changes financial terms, controls the usable balance and resolves payment liabilities. Customers would then rely on the fintech's undertaking, despite a bank BIN and a supplier label. The technical-services exclusion would not protect independently supplied issuance, accounts or e-money. The proposed restrictions address that objection by leaving enforceable payment obligations and decisive powers with the bank. (Implementing Regulations, arts. 1, 4, 6–7; Rules on Outsourcing, paras. 8–9.)
Prepaid cards, employee records and credit
The pilot should exclude credit, overdrafts and deferred repayment. A card funded solely by the employer's existing money is not a credit card merely because it carries a Visa mark. SAMA's credit-card definition requires a credit facility and includes charge cards with full monthly repayment. Cash collateral does not eliminate that distinction if the issuer still advances credit. The prepaid rules separately prohibit overdrafts on prepaid records. (Rules of Issuance and Operation of Credit Cards, art. 1; Prepaid Payment Services Rules, para. 1.2.1(8).)
A true debit card would draw directly on the company's bank deposit account rather than on a prepaid master record. The product's account and repayment terms would determine that classification. The corporate prepaid record requirements should not be imposed on every bank debit product by analogy. The recommended structure deliberately chooses prepaid records, which makes those specific requirements relevant. (Implementing Regulations, arts. 1, 6(3); Prepaid Payment Services Rules, paras. 1.2.1, 2.4.2.)
Al Rajhi's published corporate card conditions address several card types and contain provisions concerning balances and credit facilities. The pilot therefore needs an express prepaid schedule that excludes any borrowing or charge-card facility. It should specify authorization holds, settlement mismatches and recovery of erroneous credits without implying an agreed credit line. A later promise to pay merchants before the company funds the balance would require a renewed credit and issuer-permission assessment. (Al Rajhi Bank, Corporate Cards Terms and Conditions, cls. 2–3; Rules of Issuance and Operation of Credit Cards, art. 1.)
The corporate prepaid record rules constrain unrestricted virtual-card generation. Each payment device requires its associated electronic subrecord, and the rules permit one employee subrecord under each corporate contract. These provisions do not expressly state a universal one-PAN rule. The conservative pilot should nevertheless provide one approved instrument per employee, initially selecting a virtual or physical cohort. Additional PANs, disposable cards and linked tokens should wait for the bank's documented mapping of devices to compliant records and the required product approvals. (Prepaid Payment Services Rules, para. 2.4.2(2), (10).)
Employee identity checks, employer mandates and the restrictions on credits into subrecords must remain in the issuer's process. The platform should fund spending authority through the corporate master record, without accepting third-party or employee top-ups. Budgets for departments or projects should remain software classifications unless the issuer approves a lawful account structure. Corporate contracting does not remove the prepaid rules' express company and employee protections. Nor should consumer-credit procedures be copied wholesale into this non-credit product. (Prepaid Payment Services Rules, paras. 2.4.2, 2.8.3–2.8.7; Implementing Regulations, art. 51; Rules of Issuance and Operation of Credit Cards, art. 1.)
An authorized Saudi group issuer
A locally authorized Saudi group entity offers greater control, at the cost of becoming the accountable payment provider. If that entity accepts corporate funds and owes redeemable stored value, it should apply for the appropriate EMI permission and the card-related services it will provide. A payment institution (PI) route requires a structure that does not make the PI an e-money issuer, together with authorization for its actual account, issuance or execution functions. A sponsor bank holding a settlement account does not extinguish the group's own customer liability. (Implementing Regulations, arts. 1, 6, 8, 43–44.)
A Major EMI needs initial capital of SAR 10 million. Its default maximum customer balance is SAR 100,000, and its default aggregate monthly customer payment limit is also SAR 100,000. SAMA may increase those limits. Micro EMI default limits of SAR 20,000 for balances and monthly transactions are still less suitable for a broad corporate programme. Employee cards cannot be assumed to multiply a corporate customer's permitted balance. For comparison, the initial capital requirement for a Major PI is SAR 3 million. These are licensing floors and limits, not a complete launch budget. (Implementing Regulations, arts. 43(1), (4)–(6), 44(1).)
The Saudi EMI should contract as issuer and e-money debtor. The company would fund the EMI's specified collection arrangement, and the EMI would record the resulting customer entitlement. The EMI must safeguard client funds immediately on receipt. Under the proposed bank-account method, funds still held at the end of the next business day must be in the prescribed segregated account. The designated bank account is in the PSP's name for its clients' funds; it is not an ordinary account held separately by each corporate customer. Safeguarded balances must remain separate from fees, expenses and the provider's own money. (Implementing Regulations, arts. 93–94.)
The EMI would control the customer ledger and remain responsible for execution, redemption, refunds and complaints. Its settlement bank, processor and scheme sponsor would operate under their respective contracts. Daily reconciliation must connect customer liabilities, safeguarded funds, authorization holds and unsettled transactions. The customer's claim against the EMI should not be advertised as a direct bank deposit or as an unqualified guarantee against loss. SAMA's safeguarding requirements include restrictions on encumbrance and return of client funds on the PSP's bankruptcy. (Implementing Regulations, arts. 27, 93–94.)
Payment terms, fees and customer acceptance could then belong to the licensed Saudi entity within its permitted scope. It would also carry the applicable AML, technology, reporting, confidentiality and outsourcing responsibilities to SAMA. The Egyptian parent could not substitute its own name as issuer unless it separately satisfied the Saudi authorization requirements applicable to that activity. Licentium's payments and e-money licensing guide covers funds-flow assessment and the application dossier. (Implementing Regulations, arts. 4, 8, 20, 34–37.)
A sponsored programme with an unrelated Saudi EMI would use the same EMI liability and safeguarding principles. That authorized PSP, rather than Saudi TechCo, should sign the payment terms, owe the stored value and handle refunds and disputes. Its particular licence must cover the proposed services and its customer limits must accommodate the programme. It would remain accountable to SAMA for its agents, processor, data handling and outsourced functions. Selecting a third-party EMI therefore changes the issuer and funds structure from the recommended bank-account model. (Implementing Regulations, arts. 6, 24, 27, 43, 93–94.)
Foreign-issued cards offered to Saudi users
An offshore-issued model does not provide a general exemption for this proposed Saudi offering. Article 4 reaches invitations, inducements and marketing directed at persons in the Kingdom, alongside other territorial connections. Saudi-company onboarding, local SAR collection and a Saudi-resident employee proposition therefore require a Saudi perimeter assessment even when the BIN and issuer sit abroad. The regulated Saudi acquirer at the merchant end supplies a different service; its permission does not authorize the offshore issuer's customer offering. (Implementing Regulations, arts. 4, 6.)
Under a genuinely offshore contract, the foreign issuer would owe the balance, maintain the payment account and handle authorization, settlement, redemption and disputes. Its funding account, safeguarding arrangement and customer remedies would depend on the issuer's home law and terms. Those arrangements should not be presented as Saudi bank deposits or Saudi EMI safeguarding. The Egyptian fintech would need its own defined role under the foreign issuer's permissions and contracts, while Saudi territorial restrictions would remain a separate question. (Law of Payments and Payment Services, arts. 4–5; Implementing Regulations, arts. 4, 93.)
A materially different case would involve an Egyptian employer contracting abroad, funding its own foreign corporate account and sending an employee temporarily to Saudi Arabia. Incidental card use during that visit differs from selling a prepaid programme to Saudi subsidiaries. The identity and residence of the contracting customer, solicitation, funding origin, local collection, employee residence and account liability could change the territorial application. No automatic travel, reverse-solicitation or foreign-BIN exemption should be inferred from that distinction. (Implementing Regulations, art. 4.)
Offshore issuance may also introduce foreign currency conversion, cross-border transfers and Egyptian payment operations. A card issued against an Egyptian employer's credit facility differs from the proposed Saudi company's prefunded SAR card. The issuer's home authorization, regional scheme permissions and allocation of foreign-exchange costs must fit the actual branch. Because the selected pilot keeps customer funding in Saudi Arabia, it should not launch through the offshore alternative. (Implementing Regulations, arts. 4, 6.)
Egyptian management and funding
The launch conditions should require documentary confirmation that each Egyptian entity's activities and overseas arrangement are lawful for its assigned role.
The first product should exclude Egyptian customer funds, Egyptian wallet top-ups and parent-company transfers into employee spending balances. Egyptian capital contributions and genuine service payments should remain separate corporate transactions through permitted banking channels. The corporate funding model should avoid representing a software subscription as a remittance or stored-value product.
AML, data and network obligations
The issuing bank must identify the Saudi customer, its beneficial owners and authorized signatories, then monitor the relationship and transactions. The Egyptian parent group's previous onboarding should not substitute for the Saudi bank's assessment of a separate Saudi subsidiary. The bank should screen users, investigate unusual funding and merchant patterns, retain records and make required suspicious-transaction reports. A software supplier can support checks without inheriting the bank's statutory reporting decision or relieving its responsibility. (Anti-Money Laundering Law, arts. 7, 12–16; Implementing Regulation, paras. 7/3, 7/8, 7/10–7/11.)
The bank should determine payment-processing purposes and responsibilities under Saudi data law. The employer may separately control employment and expense-management processing. Contract labels should follow those actual decisions, with Saudi TechCo acting only on documented instructions where it is a processor. Data schedules should identify receipts, transaction details, identity records, device information and access logs, with retention and access rules for each. Overseas remote access can constitute a data transfer even when servers remain in Saudi Arabia. (Personal Data Protection Law, arts. 1, 8, 29; SDAIA, Standard Contractual Clauses, definition of personal-data transfer.)
Saudi data law does not establish an unrestricted export right upon obtaining consent. Its transfer requirements operate alongside SAMA's banking confidentiality, outsourcing and cloud controls. SAMA requires prior written non-objection for outsourcing abroad. For hybrid or public cloud services, the bank must obtain SAMA approval before using the service or signing the provider contract, including for Saudi hosting. The cloud controls require Saudi hosting in principle and approval for hosting outside the Kingdom. The pilot should keep live payment and identity data in approved Saudi infrastructure. Any later Cairo production access should pass the transfer, security and offshore-outsourcing gates before access begins. (Personal Data Protection Law, art. 29; Rules on Outsourcing, paras. 24–26, 42; Cyber Security Framework, para. 3.4.3, controls 4(a)(2), 4(b)(1).)
Scheme compliance requires a separate workstream. Visa's published rules require member contracts and registration for relevant third-party agents, preserve issuer responsibility and regulate the issuer's control over application approval. Payment Card Industry (PCI) security obligations and card-personalization controls also attach to the relevant participants. The issuing bank should document which Visa and domestic-network requirements apply to the proposed physical, virtual and tokenized products. Scheme approval, processor certification and a working API must not be represented as a Saudi card issuing licence. (Visa Core Rules and Visa Product and Service Rules, 18 April 2026, rules 1.9.8.5–1.9.8.6, 1.9.9.3, 10.2.2.2, 10.2.2.6–10.2.2.9; Law of Payments and Payment Services, art. 4.)
Contract conditions and launch sequence
The minimum contract package should comprise the bank-company account and prepaid agreement, employee mandates, the company-TechCo software agreement and the bank-TechCo services agreement. The Egyptian parent's subcontract should define permitted development work and prohibit unauthorized production access. A responsibility schedule should assign every issuance, onboarding, authorization, ledger, settlement, refund, complaint and data action to a named entity. The bank's final powers must appear in access permissions and operating procedures as well as contracts. (Prepaid Payment Services Rules, paras. 1.2.1, 2.4.2, 2.8.4–2.8.7; Rules on Outsourcing, paras. 18–20.)
The services agreement should provide SAMA and bank audit access, incident reporting, continuity testing, subcontractor approval, termination assistance and data return. A step-in arrangement should permit the bank to continue servicing cards when Saudi TechCo fails. The bank should be able to revoke API credentials, extract records and communicate directly with employers. Liability clauses should allocate operational losses without attempting to contract away the bank's regulatory responsibility. No supplier lien should obstruct access to customer money or legally required records. (Rules on Outsourcing, paras. 8, 18–20, 24–26, 33–34.)
First, the parties should freeze the legal entities, funds flow, card classification and decision matrix. They should then agree the bank's permitted product, the employee record structure and separate Egyptian legal and licence clearance. Customer solicitation and production integrations should wait for the necessary approvals and executed agreements. A Saudi PSP applicant cannot begin regulated operations merely because it has in-principle approval. (Implementing Regulations, art. 15(4); Prepaid Payment Services Rules, paras. 2.2.1, 2.4.2.)
The bank should establish the applicable new-product submission route with SAMA. The 2023 banking-product regulation distinguishes qualifying notifications from applications requiring non-objection; outsourcing and agent approvals remain separate questions. After completing the applicable route, the bank should test customer acceptance, funded authorization, refunds, employee departures, fraud blocks and supplier failure. The first cohort should use one approved instrument per employee, with domestic SAR spending and no cash withdrawals or cross-border funding. Physical and virtual formats should follow their approved product and network specifications. (New Banking Products and Services Regulation, paras. 4.2, 7.1–7.2; Rules on Outsourcing, paras. 9–10; Prepaid Payment Services Rules, para. 2.4.2.)
A product change should trigger review before deployment whenever it changes the debtor, regulated service or decisive operational control. Triggers include fintech-held balances, independent customer acceptance, customer payment accounts, payment initiation, merchant acquiring, additional employee subrecords, open credit, cash access, foreign-currency funding and Egyptian production operations. New offshore access, an agent role or a material subcontract also requires its applicable approval assessment. If the group insists on its own issuance undertaking or e-money liability, it should move to the matching Saudi authorization before offering that feature. (Implementing Regulations, arts. 6, 20, 24, 27, 39, 43; Rules on Outsourcing, paras. 9, 19, 42.)