Skip to content
Caramel.
← All products

Product · Infrastructure · Banks and fintechs

Blockchain as a module of the bank, not a project apart

Custodied wallets, stablecoin payments and a compliance engine, behind a single API.

Origin
A product of our own
Industry
Banks and fintechs
Model
No licence cost; the implementation is what is charged

The problem

A bank is now asked for what was experimental two years ago: moving stablecoins, custodying digital assets, settling in minutes rather than days. Building it in-house is not one project but three: a team that knows chains, a key custody arrangement the risk function will accept, and an anti-money-laundering story that survives an audit.

Each of the three can be solved. The problem is that they have to be solved together, before the first peso moves, and that none of them resembles what the core banking platform already knows how to do.

The answer

Riel puts those three things behind a single API. The bank asks for a wallet, orders a payment or reads an activity feed with REST calls, and on the other side sit the wallet with its encrypted keys, the on-chain transaction and the record that explains it.

Compliance is not a check that runs afterwards: it runs inside the transaction path. Before an operation is confirmed it passes through configurable rules, temporal patterns and screening against sanctions lists, and comes out with a risk score and, where it applies, an open alert.

The platform covers the gas. The end user does not have to understand what a network is, or hold a balance in another currency to move their own: they see an operation of their bank.

What we built

Six modules sharing one API and one dashboard. The bank integrates the one it needs and adds the others when it wants to, without redoing the integration.

What we proved

3
Compliance layersRules, temporal patterns and sanctions
<10 ms
Rule evaluationThe first layer, synchronous, inside the transaction
8
Scoring factorsWeighted, scoring 0 to 100 across four tiers
4
Circuit breakersPeg, volume, error rate and treasury

The four figures describe the engine, not an operation: they are the parameters compliance runs with inside every transaction.

The technical surface

One integration, not six. These are the endpoints the bank consumes; the admin dashboard uses the same ones.

Implemented

The platform API

REST, with token authentication

POST /api/v1/quotes
A quote from pesos to stablecoin, with an expiry.
POST /api/v1/transfers
A transfer between users, with the gas covered.
POST /api/v1/payments/requests
A payment request that expires, for another user to pay.
GET /api/v1/users/:id/activity
A unified history of purchases, sends and payments, with filters.
GET /api/v1/admin/compliance/rules
The compliance rules the bank's own team configures.
GET /api/v1/admin/compliance/alerts
Open alerts and where they sit in review.

Honesty by design

Sanctions screening runs against lists — OFAC, the European Union, the United Nations and Argentina's UIF — with fuzzy name matching. There is no external on-chain analytics provider behind it: if the bank needs one it can be integrated, but it does not come included.

The rules are defined by the bank's compliance team, not by us. Riel brings the engine and the dashboard to write, evaluate and audit them; the judgement belongs to the function that answers for it. Key custody is agreed too: it can sit with the bank, with us, or be split between the two.

How we do this at Caramel

  • Advise

    Surveying the operation, mapping the integrations and defining the risk rules alongside the compliance function, before any code is written.

  • Build

    The integration with the bank's systems, the configuration of the instance, and the dashboard the team operates without asking development for anything.

  • Run

    Monitoring the platform, the system wallets and the circuit breakers, and evolving the rules when the regulation changes.

Architect-led · Engineer-built · Production-proven

Stack

Shall we test it on your data?

Request a demo