Fintech and investment management platforms evaluated for Saudi financial services and investment firms.
Fintech is the one category on this site where the software decision is the second decision. The first is what you are permitted to do, and by whom, and that answer is not in any vendor's documentation. A savings product, an investment platform and a fundraising platform can look like three variations of the same application and sit under three different supervisory regimes - and the cost of discovering that after selection is measured in a licensing timeline, not in a change request.
So this page does something the others do not: it puts the regulatory question before the product question, and it refuses to answer it. Not because the answer is difficult, but because the only answer safe to act on comes from the competent authority and from counsel, in writing, about your specific model. What we can do is show you the shape of the question and which layers of technology it lands on.
Our interest, stated before the argument: Trustangle is an independent advisory firm. We deliver selection and implementation work, which is a genuine commercial interest in your decision, and you should have that before you read further. Where we hold a partnership or accreditation with a vendor named here, it is published on our partners page rather than implied in the copy. We do not earn a margin on your licence, and we are not your legal or regulatory adviser - where this page points at an authority, it means go and ask them.
This category also sits where our two lines of work meet. If you are a financial institution modernising, start from banking and financial services. If you are standing up a financial business in the Kingdom, the licensing and entity questions come first and are covered in market entry advisory.
"Fintech" is a label for at least five distinct product shapes that share plumbing and share almost nothing else. Set out in the order a buyer usually meets them.
Savings and deposit products. Platforms that hold, pool or schedule customer money toward a goal. The technology is modest, the obligations are not, because the moment customer funds are held the question of who is permitted to hold them and on what terms becomes the whole project.
Investment and wealth platforms. Onboarding and suitability, portfolio construction, order routing and execution, custody and reconciliation, reporting and statements. The layer with the most demanding correctness requirements on this list: a reconciliation break in an investment platform is not a data-quality issue, it is a client-money issue.
Fundraising and capital-raising platforms. Matching capital with businesses or causes, with the investor-protection obligations that attach to whichever side is being solicited. The regulatory surface differs sharply depending on whether what is being offered is a security.
Payments and collections. Acceptance, disbursement, settlement and reconciliation. Frequently the first fintech capability an operator needs, and the one most likely to already be solved by a provider rather than by a platform.
The shared spine: onboarding, identity, risk and compliance. Customer onboarding and identity verification, anti-money-laundering screening and transaction monitoring, risk scoring, audit trail, regulatory reporting, and the data protection that runs under all of it. This is the layer that decides whether a fintech project succeeds, and it is the layer most likely to be absent from a demonstration, because it is unglamorous and expensive.
Two things make this category harder to shop than the others. Vendors in each shape extend into the neighbouring ones, so a savings platform will show you investment features and an investment platform will show you onboarding, each competently enough to demonstrate. And the gap between "the product can do this" and "you are permitted to do this, here, with this product" is wider in fintech than anywhere else on this site.
The financial sector is one of Vision 2030's stated development priorities through the Financial Sector Development Program, and the Saudi Central Bank and the Capital Market Authority have each published routes for financial technology activity, including supervised testing arrangements, supported by the joint Fintech Saudi initiative. The practical consequence for a buyer is that there is a published path to ask about, which means there is no excuse for guessing.
When you do not need this yet. If the model itself is unsettled - what you sell, to whom, under which permission - software will freeze a model you have not finished designing, at the point where changing it is most expensive. And if the answer to "what is our regulatory position" is a shrug, that is the project, and it is not a technology project.
Every evaluation starts from your model and your permissions rather than from a feature grid. In this category a feature grid is actively misleading, because the features that matter most are compliance behaviours that no vendor puts on a comparison sheet.
What exactly is the product, in one sentence, and does it involve holding customer money. Who supervises it - and if the answer is uncertain, that is finding number one. Are you licensed, applying, or exploring. What already exists in your estate and under what contract. Who will own compliance configuration after go-live. What your reporting obligations are and who produces them today.
The platforms we work with in this category - Eddekhar and Fundraizerly - are described on their own pages, in their vendors' own terms. Nothing is claimed for either of them here: in this category above all others, a capability claim made on a third party's behalf is a claim someone may act on.
Where the fit is not right - and for a regulated institution it frequently is not - we say so and point at the adjacent work. Core modernisation is a banking and financial services sector conversation, and payment acceptance is usually a payments and e-invoicing question rather than a platform purchase.
Compared here are the layers of the category, not the products against each other - a product comparison would be a vendor capability claim, and those are not made on this page.
| Layer | The decisive question | Regulatory weight |
|---|---|---|
| Savings / deposit | Who may hold customer funds | High - ask the supervisor first |
| Investment / wealth | Suitability, custody, reconciliation | High - client-money correctness |
| Fundraising | Is the offering a security | High - investor protection |
| Payments / collections | Which provider, not which platform | Supervised activity |
| Compliance spine | Onboarding, screening, monitoring, reporting | The layer everything rests on |
We publish the drivers, not a price. What decides the bill here: whether the platform is licensed per customer, per transaction or per assets held, and how your growth multiplies that; the compliance spine, which is frequently priced separately and is the line most often missing from a first quote; integration to identity, banking and payment infrastructure, one line each; regulatory reporting build, which is not a feature so much as a project; audit, penetration testing and any supervisory review your regime requires; and the run cost - who owns compliance configuration after go-live, which in this category is a named role, not a spare afternoon.
The three-year total is what matters, and in fintech the compliance and integration lines routinely exceed the licence line.
Structural only. This section names authorities and the shape of their remit. It states no rule, no threshold and no licence category, and it is not regulatory advice. Confirm your position with the competent authority and with counsel.
Who supervises what. The Saudi Central Bank supervises banking, finance companies and payment services in the Kingdom, and operates published routes for financial technology activity including supervised testing arrangements. The Capital Market Authority regulates securities activity and the capital market, with its own published arrangements for financial technology. Which of the two your product falls to - or whether it falls to both, or to neither - is the single most consequential question in this category, and it is determined by what your product actually does rather than by what it is called. Fintech Saudi, a joint initiative of the two authorities, publishes orientation material for firms working out where they sit.
Open banking. The Saudi Central Bank has published an open banking framework for the Kingdom, which is the relevant reference where a platform needs access to customer banking data or payment initiation.
Identity. Customer onboarding in this market rests on national digital identity infrastructure rather than on document upload alone. Whether a platform can integrate with the national identity and verification services is a selection criterion in Saudi Arabia in a way it is not in most markets. Confirm the current services and access routes with the competent authority before relying on a vendor's claim.
Financial crime. Anti-money-laundering and counter-terrorist-financing obligations attach to supervised activity, and they land squarely on the onboarding, screening, monitoring and record-keeping layers of whatever you buy. Your supervisor is the source of the applicable requirements.
Personal data. A fintech platform holds identity documents, financial position and transaction history. The Personal Data Protection Law and its implementing regulations, with the Saudi Data and AI Authority as competent authority, govern processing, consent and transfers.
Cybersecurity. Financial-sector entities fall within published cybersecurity expectations, from the National Cybersecurity Authority and from the sector supervisor. Hosting, access and third-party connectivity belong in the selection criteria rather than in a later finding.
Shariah-compliant product structures. Many savings and investment products in this market are structured to be Shariah-compliant, and that structure has direct technical consequences - in how a product is modelled, how returns are calculated and reported, and what the platform must be able to represent. A platform that cannot express your product's structure is not a configuration problem; it is the wrong platform. Confirm structure and governance with your own Shariah advisory arrangements.
Tax and invoicing. Where the business issues commercial documents, the Zakat, Tax and Customs Authority's e-invoicing regime applies like any other.
Establishing the entity. If the financial business does not exist yet, the licensing question and the entity question are the same project. See market entry advisory and company formation in Saudi Arabia.
Discovery starts with the product definition and the supervisory question, in writing, and stops there until both are settled - we will not shortlist software for a model whose permission is unknown. Then a written shortlist with the reasoning visible, including the case for a provider rather than a platform. Scripted demonstrations weighted toward the compliance spine, not the customer interface. A commercial review of the full three-year picture. Implementation sequenced compliance-first: onboarding, screening and reporting proven before customer-facing features, a controlled pilot, and reconciliation running clean before volume. Training is aimed at whoever owns compliance configuration after we leave, because in this category that role is the control.
We do not publish a number, and in this category the software timeline is often not the binding one - the regulatory timeline is. What sets the software half: how many integrations to national infrastructure, how much of the compliance spine is in scope, whether data migration from a live product is involved, and how much regulatory reporting has to be built. We give a dated plan after discovery, and it is always expressed relative to the regulatory path, not independent of it.
Licence plus the compliance spine plus integration to identity, banking and payments plus regulatory reporting plus audit and testing plus the named internal owner of compliance configuration. Section 5 lists the drivers. A quote that prices only the licence is not a three-year number, and here it is usually not even half of one.
Compliance is not a property a product has. It is a property of a permitted activity, carried out by a licensed entity, using a system configured to support its obligations. The authorities to ask are the Saudi Central Bank, the Insurance Authority where the activity is insurance, or the Capital Market Authority depending on your activity, the Saudi Data and AI Authority for personal data, and the National Cybersecurity Authority together with your sector supervisor for security. Where a platform is hosted, and whether that is acceptable for your regime, is a question to put to the vendor in writing and to your supervisor - not one to take from a sales deck or from this page.
We publish the shortlist and the reasoning with every recommendation, including what we rejected and why. A recommendation that arrives without that is not independent advice, whoever wrote it.
Often, and for an established institution that is usually the better shape - the core stays, and the new capability is added beside it. The question to settle first is which system is the record for customer money and position. Two systems that both think they are is not a reconciliation problem; it is a governance failure waiting for an audit.
The heading asks for numbers. This section has none, and we would rather say so than publish a figure we cannot evidence - particularly in a category where an unverifiable claim about regulated work is a claim someone might rely on. What we would tell you to demand of any adviser here, including us: which regulated entities they have actually delivered for, under which supervisor, what they built versus what they configured, and the name of one client who will take your call. Ask in a meeting, where it can be checked.
We do not name clients without their written agreement, and in a regulated sector many clients cannot be named at all. References relevant to your activity and your supervisor are offered during evaluation, by name, with their consent.
Case material is shared under the same rule as section 10. We do not publish anonymous percentage improvements - an unattributable number is not evidence, and in this sector it is also a compliance risk of its own.
Testimonials appear here only when a real client has written and approved one. There are none invented in the meantime.
Published and maintained on the partners page, which is the single source of truth. We do not restate partnerships in body copy, where they go stale silently and where a claim is hardest to check.
Banking and financial services - the sector view, and the right starting point for an institution. Market entry advisory and company formation in Saudi Arabia - the licensing and entity path, if the business is being stood up rather than modernised. Payments and e-invoicing - where acceptance and settlement questions belong. All solutions and platforms and independent software comparisons.
Bring your product definition in one sentence and whatever you have in writing about your supervisory position. Book a decision session and we will tell you, plainly, whether this is a platform decision, a provider decision, or a licensing question that has to be answered before either. It is the third one more often than people expect, and we would rather say so on the first call than on the fourth.
