How to separate a product’s technical function from a financial one in the UAE: a practical retail-payments check

Short answer

In the UAE retail-payments example, the line between a technical product function and a financial one is not drawn by the product label or by calling the business a software platform. Under the CBUAE Retail Payment Services and Card Schemes Regulation, one of the key factual questions is whether the company takes possession of money under the relevant payment service. For technical service providers, the source describes an exclusion where the provider does not take possession of money under that payment service [1].

But that is not the end of the analysis. The same regulation also contains other exclusions and at the same time regulates a broad range of retail payment services and card schemes [1]. So “we are only a tech company” is not a conclusion. It is only the beginning of a factual review.

When this article applies

This article relies on one specific source: the CBUAE regulation on retail payment services and card schemes [1]. It is therefore useful as a UAE example in the retail-payments context.

That limitation matters.

First, this is not a universal legal test for every software, fintech or digital product.

Second, this article does not determine the licensing position of a specific business without a factual review.

Third, the working map below is an author method for internal preparation, not a regulator’s mandatory form.

If your product is outside the retail-payments context, you can still use this article as a way to think about functions, but not as a complete legal answer by itself.

Where the error starts

The problem starts if the team describes the product in presentation language:

• we provide infrastructure;
• we only connect the parties;
• we are not a bank;
• we are only a technical provider.

For internal business discussion, that may sound reasonable. For regulatory analysis, it is too broad.

The real question is usually different. You need to understand not how the product is marketed, but what actually happens inside the payment chain:

• who receives the payment instruction;
• who passes data forward;
• who participates in routing the transaction;
• whether there is any moment when the company legally or factually accepts or controls money;
• which contractual role the company holds in the chain.

That is where a technical role can stop and a financial role can begin.

What the source confirms directly

The confirmed source base for this topic supports three core points.

1. There is an exclusion for technical service providers

The CBUAE retail-payments regulation expressly describes an exclusion for technical service providers in the relevant part of the framework where the provider does not enter into possession of money under that payment service [1].

This matters because it shows the principle of distinction: infrastructure or technical support can be analysed separately from the handling of money.

2. No possession of funds does not automatically solve every regulatory question

The same regulation also lists other exclusions, including categories such as stored value facilities, virtual asset tokens, remittances and intra-group transactions [1].

The practical meaning is important. You cannot take one sentence about technical service providers and turn it into a universal rule that if money is never held, the product is automatically outside regulation. The source does not confirm that.

The better conclusion is narrower: no possession of funds is an important question, but not a universal final answer for every product.

3. The regulation covers a broad payment-services perimeter

The source also confirms that the framework covers a wide range of retail payment services and card schemes, and for some models includes contractual requirements involving account issuers and AIS/PIS providers [1].

This leads to another practical point: even where a product looks technology-heavy, the team still needs to test whether it sits more deeply inside a regulated payment chain than the marketing description suggests.

A practical rule: analyse functions before labels

The most useful approach is to separate the product into two layers.

Technical functions

These usually include infrastructure and information-processing roles such as:

• hosting;
• data transmission;
• interface handling;
• maintenance of terminals or integrations;
• software layers that allow participants to exchange messages.

That kind of role does not by itself prove that the company is handling money.

Financial functions

This is the more sensitive layer. It includes roles where the facts need closer testing:

• receiving funds;
• holding funds;
• transferring funds;
• participating in payouts;
• playing an acquiring or similar settlement-chain role;
• any point where the company factually or legally controls money, even briefly.

This article deliberately avoids over-claiming. So the safer formulation is this: the closer a function moves to receiving, holding or controlling money, the weaker the simple statement “we are only tech” becomes, and the more important a separate regulatory review is likely to be [1].

An author working map: how to test the product by facts

The framework below is not a regulator’s mandatory checklist. It is a practical internal method for product teams, owners and counsel.

Step 1. Break the product into separate functions

Do not describe the product in one broad sentence. Split it into concrete actions.

For example:

• user interface;
• transmission of the payment instruction;
• storage of payment details;
• forwarding data to a bank or another participant;
• generation of a confirmation;
• refund handling;
• fee calculation;
• participation in crediting or paying out funds.

The aim at this stage is simple: understand what the product actually does in parts, not what the full product is called.

Step 2. Ask one main question for each function

Does the company enter into possession of money in connection with this function?

That question can be broken down further:

• do funds ever arrive in an account of the company;
• can the company hold, direct or reallocate an amount;
• do funds ever pass through the company’s settlement perimeter;
• do customers or partners see the company as the party receiving payment;
• without the company’s action, is it money itself that stops moving, rather than only the data layer.

If the answer to those questions is consistently no, and the company’s role is limited to routing data or supporting infrastructure, the function is closer to a technical role in the logic of the exclusion described above [1].

Step 3. Compare the function with the exclusions and the wider context

Even if there is no possession of funds, the review should not stop there.

Ask separately:

• does the model sit inside another context mentioned in the exclusion list;
• does the product still fall within another regulated payment function;
• does the company’s contractual role go beyond a pure technical description.

This is the step that prevents the premature conclusion that “we do not hold money, so the issue is closed.”

Step 4. Draw the flow map

One diagram is often more useful than ten paragraphs.

Show:

• the user;
• the payment instrument or interface;
• the bank, issuer, acquiring side or other participant;
• the product itself;
• where data moves;
• where money moves;
• who controls each element at each stage.

For internal use, it often helps to mark data flow and money flow in different colours. If the team mixes those two routes together, confusion starts.

Step 5. Pull the documents, not only the diagram

A strong internal map is always supported by documents.

Useful materials often include:

• bank and partner agreements;
• SLAs and technical agreements;
• settlement-chain descriptions;
• billing flows;
• technical logs;
• user terms;
• internal descriptions of the company’s role in the transaction.

If the company relies on the position that it never enters into possession of funds, that point should ideally be supported by the architecture and documents, not only by a slogan.

A practical first-pass table

Below is a simple working template.

Scroll the table horizontally →

This table does not grant or remove a licence. But it quickly shows where the team has only a technical description and where a financial role may already begin.

A hypothetical example

Imagine a UAE product model.

In the first version, the product only transmits a payment instruction from the user to a partner bank. The company does not receive money into its own accounts, does not hold it and does not redistribute it. Its role is to support the interface, data transmission and technical service availability.

In that configuration, the team has a basis to test the model as technical support within the logic of the exclusion described in the regulation [1]. But even here the next step is still necessary: confirm the position through contracts, the flow map and the factual architecture.

Now imagine a second version of the same product. During the transaction chain, the company starts receiving the amount into its own settlement perimeter, even briefly, before further transfer.

At that point, the key question changes. The issue is no longer how the product is branded, but whether the role remains purely technical. The presence of that moment weakens the simple statement “we are only IT” and requires a deeper regulatory review [1].

This remains only a hypothetical example. It does not prove the licensing outcome for any real product without a detailed factual analysis.

What to prepare before speaking to counsel or a regulator

If you want a more useful answer, prepare one short evidence pack.

1. A function list

Not a pitch deck, but a list of concrete product actions.

2. A data-flow and money-flow map

Show separately where data moves and where money moves.

3. The company’s role at each step

For each stage, answer:

• who acts;
• who controls the money;
• who is the contractual party;
• who stores the confirmations.

4. Contractual documents

Pull the agreements with banks, payment partners, infrastructure providers and customers.

5. Evidence of no possession of funds, if that is your position

This may include architecture diagrams, settlement logic, banking arrangements and other materials showing that the product works as a technical layer rather than a holder or distributor of funds.

If you are preparing the operational fact map before a regulatory discussion, the separate article on what product actions to describe before a UAE licensing check may also be useful.

What this article deliberately does not claim

To avoid overstatement, the limits should stay explicit.

This article does not claim:

• that every software provider is automatically excluded from regulation;
• that no possession of funds always answers the licensing question;
• that one test works for all financial products;
• that any UAE product can be classified without reviewing contracts, payment flows and factual architecture;
• that the author’s function map replaces legal advice.

Its purpose is narrower and more practical: to help a team separate the technical layer from the potentially financial one in factual terms.

Conclusion

In the UAE retail-payments example, a product’s technical function is separated from a financial one not by the product label, but by the question of possession of funds and the company’s real role in the payment chain. The exclusion for technical service providers is a useful starting point, but not a universal exemption for any digital product [1].

The practical next step is simple: take one product scenario, split it into functions, draw data flow and money flow separately, and test whether any point in the chain creates possession of funds. Only after that should you discuss with counsel or the regulator whether the model remains technical and which rules need further review.

Sources

[1] Central Bank of the UAE, Retail Payment Services and Card Schemes Regulation, Circular No. 15/2021: https://centralbank.ae/media/4came3rh/2021-c-15-2021-retail-payment-services-and-card-schemes-reg_0.pdf

Disclaimer: This material is for general information only and is not individual legal or regulatory advice. Any conclusion on the licensing position of a specific UAE product requires a separate review of the actual payment flows, contracts, service architecture and the current applicability of the relevant rules.