Poto

Poto is an electronic money product operated inside a regulated environment. I contributed to the design and construction of the information systems behind it.

An electronic money product is not a wallet screen with a balance in it. It is an issuer obligation: units of value are received, safeguarded, issued, held, moved and redeemed, and every one of those steps has to be provable months later to someone who was not there.

That constraint decides the architecture before any product decision is made. This page describes the problem publicly, and the nature of the contribution. It contains no internal architecture, process or security detail.

Three things had to be true at the same time: the product had to work for the people using it, the operation had to be runnable by a small team, and the whole thing had to be explainable to a supervisor.

Most systems solve one of the three. Solving the first alone produces a good interface over an unauditable ledger. Solving the third alone produces a documentation project with no operating system behind it.

• Product usability
• Operational runnability
• Supervisory explainability
• Auditability by default

Design and implementation of a system able to hold electronic money and account for its movements.

The model separates what is received from what is issued, and what is held from what is spendable. Balances are a consequence of recorded movements, never a field that is edited.

Redemption is treated as a first-class operation rather than an exception, because it is the moment at which the issuer obligation is discharged.

The components a transactional system needs before a product can exist on top of it.

Work covered the pieces that make a transactional system function: accounts, wallets, transactions, rules, balances, reconciliation, control and traceability, together with the information system that lets the operation run day to day.

Internal tooling so that a control produces its own evidence.

Controls, workflows, verifications, follow-up and operational tooling were built as software inside the system rather than as a parallel manual practice.

The design rule is simple: if a control cannot produce evidence automatically, it is not finished. Evidence assembled by hand at the end of a quarter is not a control, it is an archaeology project.

• Controls
• Workflows
• Verifications
• Auditability
• Follow-up
• Operations

Contributed to the technical and operational work supporting the ACPR authorization process and its implementation.

The institution operates under ACPR supervision. The contribution here was technical, organisational and operational: producing the system evidence, the operating procedures in software form, and the data needed by the process, then keeping them true once the authorization was live.

The distinction matters and is kept everywhere on this site: an authorization is granted to an institution, not to a person.

One data structure, several projections.

Regulatory reporting work focused on structuring and automating the data behind the different reports, so that each report is a query over the operating data rather than a manual assembly exercise.

The payoff is not the report. It is that the same structure answers a supervisor, a finance team and an incident review without three different truths appearing.

Every regulated constraint eventually shows up in the interface: what a user can hold, what they can send, what has to be verified before an action, what has to be explained after it.

Designing those constraints as product behaviour rather than error states is most of the work. A refusal that a person understands is a feature; a refusal they do not is a support ticket and, eventually, a complaint.

Four things carried over into everything since.

• Rules belong in data, not in prose
• Evidence is produced, not collected
• Balances are derived, never stored as truth
• Operations are a product with its own users