The Coines app is a peer-to-peer crypto exchange built for Kuwait, and it is the clearest example we have of a product where trust, not features, is the thing you are actually shipping. This is what the hard parts looked like — onboarding, escrow, disputes and bilingual support — and which of them are worth automating.
Why peer-to-peer is harder than it looks
A centralised exchange owns both sides of every trade. A peer-to-peer platform does not — it introduces two strangers, holds value in the middle, and has to be trusted by both of them at once. That single difference drove most of the product decisions behind the Coines app. Escrow, identity, dispute handling and payment confirmation stop being back-office plumbing and become the main user experience. Anyone evaluating a peer-to-peer model should budget for that inversion early rather than treating it as a phase two concern.
In the GCC the problem is sharper still. Buyers and sellers settle with each other through local bank transfers and instant payment apps, outside the platform entirely. The product never sees the money move. It only ever sees evidence that it moved — a reference number, a timestamp, an uploaded receipt — and it has to decide how much weight each piece of evidence carries, and how long an order stays open before it expires. Get the expiry window wrong and you either strand honest users or hand a free option to bad ones. You can see the shipped product in the Coines case study.
Onboarding is where GCC fintech leaks users
Every regulated flow starts with know your customer checks, and in Kuwait that means Civil ID, passport and address documents arriving as phone photos taken in variable light. Arabic names transliterate several different ways, so a strict string match against the document rejects real people. Manual review fixes accuracy and destroys speed — a user who signs up at 11pm and waits until the next working day usually does not come back.
This is the one place where automation pays for itself immediately. Field extraction, expiry checks, face match and duplicate-account detection can clear the clean majority in seconds and route only the ambiguous cases to a human reviewer, who then sees a pre-filled form instead of a blank one. We wrote up the mechanics separately in AI document processing in Kuwait; the same pipeline that reads a Civil ID reads a delivery note or a supplier invoice.
Where AI belongs in a fintech product, and where it does not
It does not belong anywhere near the decision about whose money gets released. Escrow release stays deterministic, fully logged, and reversible by a named human. That is a rule, not a preference, and we would apply it to any payments product regardless of how good the models get.
What AI does well is everything around that decision: summarising a dispute thread so an agent reads one paragraph instead of forty messages, flagging behavioural patterns that deserve a second look, drafting the bilingual reply for a human to approve, and answering the share of tickets that are genuinely the same six questions about limits, fees and stuck transfers.
Language matters more than most teams plan for. Support arrives in Arabic, in English, and in a mix of both with Latin-script Arabic in the middle of a sentence. An Arabic chatbot that handles that honestly — answering from your real policy documents, saying it does not know when it does not, and handing off to a person the moment money, identity or a formal complaint is involved — removes the night and weekend queue without pretending to be human. The same reasoning applies across regulated sectors; we set it out for lending, insurance and accounting teams in AI automation for finance.
What we would repeat on the next one
Three things carried over into every fintech build since:
- Build the dispute console before launch. Your first dispute arrives in week one, and handling it in a database client is how you lose a user and an afternoon.
- Design Arabic first, not Arabic later. Right-to-left layout, numerals, name fields and date formats are cheap at the start and expensive to retrofit across sixty screens.
- Instrument the funnel at the document step. If you only learn that onboarding is broken from your churn number, you are already a quarter late.
Working with us on a scoped build
We quote this kind of work as a fixed price, not an open-ended rate card. It starts with a paid two-week discovery — flows, integrations, compliance constraints and a written scope — after which you get a fixed price and a fixed delivery window for the build itself, or you take the discovery document and go elsewhere with no further obligation. Fixed price means the estimating risk sits with us, which is the correct place for it.
If you are weighing up a fintech product, a marketplace with money in the middle, or an AI layer on top of an existing one, the AI services page sets out what we build and how the engagement runs.