Security model, data and liability
Who authorises a payment, what we verify and what your bank verifies, where the truth of a payment lives, and what data we hold.
Who authorises a payment
The payer authorises every payment inside their own bank's application — the one they already trust and their bank already controls. miaPOS does not collect, display or relay the payer's credentials at any point, and there is no step where a payer types anything sensitive into a miaPOS surface.
There are no cards in the flow. No card number reaches miaPOS, is stored by miaPOS or passes through miaPOS, because the payment is an account-to-account instant transfer and not a card transaction. That removes cardholder data from the picture rather than protecting it.
What miaPOS verifies, and what the bank verifies
This boundary is deliberate and worth stating plainly: miaPOS verifies nothing about a merchant applicant's identity.
When a business applies, it supplies a company identifier and the identifier of the person authorised to represent it. The bank matches that pair against its own client records and calls the administrator on the number the bank already holds. If the pair does not match, the applicant is not a client of that bank, and the answer is to open a business account — not to try the form again.
So identity, KYC and the decision to activate stay where the licence and the client relationship already are: with the bank. miaPOS carries the application and, once the bank activates it, the acceptance itself.
An earlier design used an SMS one-time code. It was dropped: a code proves possession of a SIM card, which says nothing about whether the person is connected to the company.
Where the truth of a payment lives
In the online flow, the browser holds only an opaque paymentId — a capability token that identifies a payment without carrying its terms. The amount is fixed server-side by the merchant's own backend and is never taken from the browser.
Confirmation that a payment happened is the RSA-signed webhook delivered to the merchant's backend. The browser-side success callback only redirects the buyer's tab; it is not evidence and must never be treated as such. An integration that ships value on the callback alone is misintegrated, and our documentation says so.
What data we hold
The diagnostic tools hold the least they can and drop it on a schedule: Configurator transcripts are kept for 180 days, the final report for two years, and personal contact details for two years or until an erasure request, whichever comes first.
The controllers, the retention periods and the rights of access, rectification, erasure and portability are named in the Privacy Notice. It is the binding document; this page is the summary.
What miaPOS is, and what it is not
miaPOS is a payment acceptance technology provider that works with regulated banks. It is not a deposit-holding institution, and it does not hold merchant funds: money moves between the payer's bank account and the merchant's bank account.
Payments are bank-initiated and processed under the regulation of the relevant instant payment scheme and central bank in each market. The operating entity is Finergy Tech S.R.L. (Chișinău, Republic of Moldova); EU-market operations are conducted through its Romanian subsidiary Instapay Tech S.R.L., subject to local supervisory authorities in target markets.
Questions this page does not answer
If your risk assessment needs deployment topology, the security review artefacts your process expects, or answers about a specific national requirement, ask us directly — those belong in a document addressed to your institution, not on a public page. Write to [email protected] and say which framework you assess against.