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 orchestration layer that decides, per payment, how money should move; and a rail abstraction that turns every connected bank, wallet, card network and national QR system into an interchangeable destination. Value settles on the rails of regulated institutions — MYQR routes, it does not replace.

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 orchestration 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 orchestration choose the rail, 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: routing (predicting the best rail from availability, cost and history), anomaly detection (flagging out-of-pattern flows for review), and reconciliation (matching settlement records across rails). 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 rail abstraction is where the third principle becomes engineering. Designed for ISO 20022 message semantics and open-banking interfaces, with national QR systems — MMQR among the intended pathways — treated as first-class rails rather than special cases.

Dependencies are explicit by design: every rail 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 rail is presented as live until its dependency chain is.

Current, building, future

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