Technology

Architecture

MYQR sits alongside existing infrastructure, never in place of it. The platform is three layers: an identity layer that resolves a handle to verified payment destinations; an resolution layer that decides, per payment, how money should move; and a network abstraction that turns every connected bank, wallet, card network and national QR system into an interchangeable destination. Settlement occurs on the networks of regulated institutions. MYQR resolves the destination; it does not replace the institution.

The one distinction that removes most confusion:

Security

The core security property is structural: credentials never travel with the payment. A sender addresses a handle; resolution happens inside the identity layer; the counterparty never sees account numbers, wallet IDs or card details. Security by design, not by disclosure.

Data handling follows the same boundary. Identity data lives in the identity layer under the resolution boundary; transaction routing metadata lives in the resolution layer; settlement data stays with the regulated institutions that execute it. Each layer holds only what its job requires — data minimisation as an architectural rule rather than a policy afterthought.

Compliance

MYQR is built on a regulated-partner model. The platform is designed so that every movement of value is executed by an institution licensed to execute it, while MYQR provides the identity, routing and audit intelligence around that movement. The Austrian licensing track defines how MYQR.AT's own regulatory perimeter grows over time.

Certification and licensing statements are published only when granted and attributable to a specific entity — see the Company page for the current posture.

API

The API exposes the same primitives the platform runs on: resolve an identity, create a payment intent, let the platform resolve the route, receive webhook events as the flow progresses. Idempotent requests, signed webhooks, sandbox-first. The shape below is illustrative — reference documentation ships with the developer program.

The developer program →

AI

AI assists three places in the flow: destination resolution (predicting the appropriate destination from availability, cost and history), anomaly detection (flagging out-of-pattern flows for review), and reconciliation (matching settlement records across networks). Every AI-assisted decision is logged, explainable and overridable — in payments, a model that cannot show its reasoning does not get to make decisions.

Interoperability

The network abstraction is where the third principle becomes engineering. Designed for ISO 20022 message semantics, SEPA and European instant-payment schemes, and PSD2-aligned open-banking interfaces — tracking PSD3 as the European framework evolves. National QR systems — MMQR among the intended pathways — are treated as first-class routes rather than special cases.

Dependencies are explicit by design: every network connection depends on a partnership, a scheme membership or a regulatory permission, and the platform's status page model (Building now → Next → Future, below) states which. No connection is presented as live until its dependency chain is.

Identity is European by design. The identity model is built to interoperate with emerging European digital-identity frameworks, so a MYQR handle can sit alongside — never in place of — the identities institutions already trust.

Current, building, future

The platform grows in the order the operating system stacks. Statuses are design-and-build phase, not commercial-launch claims.