Technical

The platform, surface by surface

Six client surfaces are built and demonstrable against mocked services. The production backend, licensed-partner connections and independent security testing remain pre-launch work.

This page is written for engineers and integrators; the plain-language version of each item is on the platform page.

Built: client surface implemented and demonstrable. Integrated: connected to a live third-party service. Production-ready: security-tested, monitored and approved for live funds. Saleem is currently at Built for six client surfaces; live integrations and production assurance remain in scope.

Designed: specified, not yet implemented.

Supported in demo build: selectable and demonstrable in the pre-launch client environment; not a claim of live corridor availability.

Configured in demo build: represented in the pre-launch asset configuration; legal and counterparty eligibility is confirmed per launch.

Prototype integration: technical connection demonstrated in a non-production environment; live integration and assurance remain outstanding.

The six client surfaces

What each one is, and what it does.

USSD and SIM Toolkit Built

Menus over the GSM signal on any handset with a SIM, with nothing installed and no data connection: receive, check a balance, send, and request cash.

A basic phone showing the Saleem USSD menu: 1 Balance, 2 Send, 3 Receive, 4 Cash out; illustration of the flow on the home page

KaiOS Built

A packaged app for smart feature phones, adding bill payment and merchant QR to the same wallet and the same number.

Saleem KaiOS feature-phone wallet home screen

Android Built

The full wallet: send, receive, convert, spend, savings and self-service, with a bank on-ramp where one is available.

Saleem Android wallet home screen

iOS Built

The same wallet from the same codebase, for recipients and senders who carry an iPhone.

Saleem wallet send screen from the React Native build that iOS and Android share, demo environment
same codebase as Android

Desktop console Built

The operator surface: bulk disbursement, approvals, treasury, reconciliation, reporting and the compliance console, with role-gated pages.

Saleem desktop operator console home screen

Merchant POS Built

Any phone becomes the till: charge a phone number or show a QR code, refund in the same flow, and settle to the merchant's own account.

Saleem merchant POS home screen on a phone

The settlement layer

Where value moves, and on what.

Six settlement networks, supported in demo build.

Marks shown are the property of their respective owners and indicate technical support, not endorsement.

Six settlement networks Supported in demo build

ADI Chain, Polygon PoS, TRON, Stellar, Solana and Ethereum.

Six regulated tokens Configured in demo build

Dirham payment tokens under the CBUAE regime and dollar tokens recognised by the ADGM FSRA. The recipient never handles a token.

Cross-chain bridging Prototype integration

Chainlink CCIP carries value between EVM chains and Solana where a corridor needs a chain other than its default.

Conditional release Designed

Time-locked or condition-locked disbursement, each release on the audit trail.

Multi-signature escrow Designed

Funds locked until the agreed signers authorise; maker-checker on chain.

Scheduled instalments (designed) Designed

Designed; release and repayment schedules between verified businesses and a licensed financier.

Settlement assets and networks Configured in demo build

Settlement assets: regulated payment tokens under the CBUAE regime and dollar tokens recognised by the ADGM FSRA. Rules execute on every network Saleem settles on; the first contracts are built on one network and ported per corridor.

Technical support does not mean a token, network or corridor is legally available. Eligibility is confirmed per asset, counterparty and jurisdiction.

Every network and token, with its status

The compliance layer

What happens to every transaction, and what comes out of it.

Screening Prototype integration

Counterparty risk, sanctions and on-chain analytics on every party and every transfer, with residual designations screened at each transaction.

Travel Rule Prototype integration

IVMS101 originator and beneficiary data exchanged on every settlement chain.

Custody Designed

Recipient balances are to be held by a licensed custodian and accessed through Saleem's interfaces; keys do not sit on the handset. This is the target operating model at launch. The account is the phone number, protected by a PIN.

Audit trail and export Built

Every payment, approval and spend recorded once, with maker-checker on disbursement and exports in camt.053 and camt.054, MT940, BAI2 and CSV.

Compliance by design, in full

Integration

The platform is pre-launch. Integration documentation, a sandbox and an API reference follow the production build. Institutions evaluating an integration today should talk to us and we will walk the surfaces and the data model.

Talk to us about an integration

Tell us which surfaces matter to you and what your systems expect at each end, and we will walk them with your team.

Talk to the team

Questions partners ask

What is live today, what is designed but not built, and can we audit it and export to our bank? What does a telecom operator have to build? Is it secure, and what happens when a handset is lost, shared or taken, or when the network is down? Can payments be programmed, and can a business hold the digital money?

All twelve questions