Key Takeaways
- UR carries KYC, AML, and ongoing monitoring as the licensed operator. Partners integrating via UR's API inherit the regulatory perimeter rather than securing their own — onboarding flows must meet UR's standards, and users pass through UR's verification before an account is issued.
- UR is regulated under SR Saphirstein AG, licensed under Article 1b of the Swiss Banking Act and supervised by FINMA. That license is what makes the accounts UR issues real financial accounts, not database entries — and is the structural reason the regulatory burden does not fall on the partner.
- User deposits on UR are segregated at the protocol level, not through internal accounting. Every UR account is a named personal Swiss IBAN backed 1:1 by tokenized deposits in seven currencies (EUR, USD, CHF, RMB, SGD, JPY, HKD) — not a beneficiary interest in a pooled platform account.
- Fiat and stablecoins sit inside a single regulatory perimeter on UR. Because UR holds the fiat rail (SEPA, SWIFT, Swiss SIC) and the tokenized deposit issuance under the same license, the compliance chain does not break at the fiat-to-stablecoin interface — the gap most conventional stacks rely on bridge logic to manage.
The Question Every Platform Should Ask Its Infrastructure Provider
When a wallet, exchange, or fintech integrates a financial account layer, they're not just adding features. They're inheriting a compliance posture, a regulatory relationship, and a security architecture — whether they know it or not.
This article answers the questions that every responsible platform operator should be asking before they go live: who carries KYC and AML liability, how deposits are protected, and what compliance is actually built into the infrastructure.
Summary: Security That UR Provides at the Infrastructure Level
UR is the account layer that anyone can build on.
Who Is Responsible for KYC and Ongoing Monitoring on UR?
This is the first question any compliance or legal team should ask — and it deserves a direct answer.
UR operates as a regulated entity under SR Saphirstein AG, a fintech licensed under Article 1b of the Swiss Banking Act. That means KYC and AML obligations are not deferred to the partner. UR performs identity verification for every individual and business that opens an account on the platform, issues a URID (UR Identity) after verification, and carries ongoing monitoring responsibilities as the licensed operator.
For partners integrating via UR's API, this structure is a significant advantage: the compliance burden does not fall on the platform to replicate. Partners only need to operate within UR's framework — meaning their product flows must meet UR's onboarding standards, and their users pass through UR's identity verification before an account is issued. This is the same structure used by any company that issues financial accounts through a licensed banking or payment institution.
Because every transaction on the UR platform moves through onchain rails with an immutable audit trail, ongoing AML monitoring has structural support that traditional BaaS providers cannot offer — the transaction history is not a database record that can be amended; it is a verified onchain log.
How Are User Deposits Protected?
Deposit protection is where UR's architecture diverges most sharply from conventional fintech infrastructure — and from how competitors typically approach the question.
Providers like Zero Hash and BVNK each address asset protection through custody arrangements, segregation policies, and third-party attestation. These are meaningful controls and operate on a traditional model: user funds sit in a custodial or pooled structure, documented in internal ledgers, with segregation enforced by process.
UR takes a structurally different approach as an alternative for consideration.
Every UR account holds tokenized deposits — each unit backed 1:1 by real fiat reserves, held in segregated, named personal IBAN accounts. A user's EUR balance is not a ledger credit against a pooled float. It is an onchain tokenized euro (EUR24, or the equivalent in any of UR's seven supported currencies) that represents a direct claim on a segregated reserve. The segregation is structural, not procedural.
This matters for three reasons:
-
Individual-named IBANs. Each UR account is a named personal IBAN — not a virtual account number routing to a shared pool. The account belongs to the user in the way a traditional bank account does, not as a beneficiary of a platform-level arrangement.
-
Onchain transparency. Because deposits are tokenized, the reserve backing them is verifiable. This is a form of transparency that traditional custody arrangements, even with third-party attestation, cannot match structurally.
-
Segregation by design. The separation between user funds and platform funds, and between one user's funds and another's, is enforced at the protocol level — not maintained only through internal accounting controls.
UR supports 7 currencies in this structure: EUR, USD, CHF, RMB, SGD, JPY, and HKD, plus USDC and other customized tokens as natively supported stablecoins for on/off-ramp and in-app conversion.
How Does UR Handle Compliant Fiat-to-Stablecoin Movement?
The movement between fiat and stablecoins is a significant regulatory fault line.
UR's architecture treats fiat and stablecoins as part of a single, continuous account rather than as separate systems that need to be bridged. Here is how the flows work:
Fiat in, tokenized deposit. A user deposits euros via SEPA. The euros land in their named Swiss IBAN. The UR account reflects the balance as EUR24 — a tokenized euro backed 1:1. The rails are SEPA; the representation is onchain. No separate conversion step; no movement between a "fiat account" and a "crypto wallet."
Stablecoin in, recognized and held. Users can receive USDC or USDT directly into their UR account. These are held natively — no forced conversion to fiat. They appear alongside tokenized fiat deposits in the same account.
Cross-asset conversion. Users convert between tokenized deposits and stablecoins at competitive spreads within the UR interface or through the API. Every conversion is logged onchain.
Stablecoin out. Withdrawals to external wallets are processed as onchain transfers with a verifiable audit trail.
The compliance posture here is structural: because UR is the regulated issuer and every transaction moves through UR's licensed infrastructure, the fiat-to-stablecoin movement occurs within a single regulatory perimeter — not across two separate regulated entities with a compliance gap between them.
For platforms building cross-border payroll, treasury, or B2B payment products on top of UR, this means the compliance chain does not break at the fiat/stablecoin interface.
What Audit Trails and Event Logs Does UR Provide?
For any platform that needs to demonstrate compliance — to regulators, auditors, or enterprise customers — the quality of the audit trail is a primary concern.
UR's architecture provides a materially stronger audit trail than conventional BaaS platforms because the underlying ledger is onchain and immutable. Transactions cannot be amended after the fact. The record of what happened — who sent what, to whom, at what time, and on which terms — is embedded in the blockchain, not maintained solely in a database that an administrator can modify.
For platforms integrating via UR's API, the following event data is accessible:
Webhooks. UR's API surfaces real-time webhooks for account events, transaction events, and status changes. Platforms can pipe these events directly into their own logging and monitoring infrastructure, ensuring the audit trail is not trapped inside UR's system but flows into wherever the partner needs it.
Onchain transaction logs. Because UR's tokenized deposits and payment operations are onchain, the transaction history is verifiable independently of UR's own reporting. A partner or regulator with the relevant onchain address can verify the history without relying solely on UR-provided data.
Account statements and reporting. UR provides programmatic access to account data, statements, and transaction history via API. Tax reporting data is part of the account data structure.
Smart contract audit trails. UR's compliance rules are implemented as smart contracts. The enforcement of rules is code — meaning the audit trail includes not just the transactions but the contractual logic under which they executed.
This is a qualitative difference from traditional BaaS, where audit trails depend on the provider's internal record-keeping. Onchain infrastructure means the audit trail is third-party verifiable by default.
How does UR manage user risk across the partner ecosystem?
Because UR accounts are individually named, IBAN-bearing accounts backed by segregated reserves — not beneficiary interests in a platform-level account — the structure is more resilient to platform failure than typical BaaS arrangements.
In a traditional BaaS model, user funds often sit in a pooled account held in the name of the platform operator. If the platform operator fails, user funds may be caught in insolvency proceedings before they can be returned. This is the scenario that has caused user losses in several high-profile fintech failures.
In UR's model, the account belongs to the user — it is their named IBAN, their segregated deposit, under UR's regulatory framework. The partner platform is an integrator, not the account holder of record, and thus, does not affect the integrity of the user's account.
This is not a guarantee against all scenarios — any financial architecture has edge cases — but the structural design is materially more protective than pooled-fund BaaS models.
UR's differentiation is architectural. Our compliance is code, and segregation is structural.
The next compliance problem is already here. For platforms evaluating account layer providers, the question is not just "how secure is this provider?" but "how is security enforced, and can that enforcement be verified independently?" UR's onchain architecture makes the answer to that second question verifiable by design.
And with AI agents entering the financial system, the way we look at compliance will soon see another shift. Autonomous agents are already managing treasury flows, executing cross-border payments, handling payroll disbursements, and settling compute costs across jurisdictions, around the clock, without a human approving each transaction. They generate more financial activity than the users who deploy them. They operate across time zones simultaneously without rest.
The platforms that ensure security and maintain regulatory footing in this changing landscape will build once — on infrastructure that is programmable by default, auditable by design, and regulated from the start. The security posture that makes UR trustworthy for a user receiving salary through a personal IBAN today is the same posture that makes it the right substrate for autonomous treasury agents tomorrow.
That convergence — human finance and machine finance, operating on the same compliant, onchain account layer — is what UR was built for.
