PAYMENT PIN

A payment PIN on every outgoing transfer

Money should not move on a session cookie. In FinLabCore’s client apps, every outgoing transfer and currency exchange is signed with the user’s personal Secure Payment Confirmation PIN, identity confirmed at the moment of authorisation, not just at login.

All client-app features →

Identity-verified setup: SMS before you set your PIN

The PIN begins in account settings, and begins with proof: an SMS identity check gates creation, so only the verified account owner can set it. Entry is masked with show/hide, and a real-time requirements checklist guides the user to a valid PIN without trial-and-error. Changing it later is layered the same way: SMS verification plus the old PIN or the account password.

Sign, revoke, and track every authorisation

At the moment of payment, the signing modal asks for the PIN, a valid entry confirms identity and signs the operation. For accounts with multiple signers, authorisation is a visible state, not a mystery: per-signer status, needs signature, signed, revoked, with timestamps, and signatures that can be revoked while revocation is possible. The client-side half of the platform’s four-eyes model, in the user’s hands.

Built-in safeguards: wrong PIN, insufficient funds, nothing debited

The failure modes are designed, not accidental: a wrong PIN stops the action with a clear retry path and the transaction stays unsigned; insufficient funds stop it just as cleanly, and in both cases, nothing is debited. The rule the user learns fast: until the PIN signs it, the money has not moved.

Payment PIN FAQ

Which operations require the PIN?
Outgoing transfers and currency exchanges, the operations that move value are the operations that get signed.
Only the verified account owner: setup requires SMS identity verification, and changes require SMS plus the existing PIN or the account password.
The action stops, the transaction remains unsigned, nothing is debited, and the user can retry, an error, not an incident.
Per-signer status with timestamps, needs signature, signed, revoked, visible on the operation, so “who still needs to sign” is a glance, not a group chat.
It is the client-side signature; policy-based back-office approval and four-eyes controls sit on the institution’s side of the same movement.

Sign a payment in the demo, then get it wrong on purpose

The correct PIN signs; the wrong one safely does not. Both halves are worth seeing.