Compliance here is not a document that sits beside the product. Identity, custody, protocol and platform are separate control layers, owned by separate systems, and a transaction passes through all four before anything settles. This page sets out what each one does and what it refuses.
The question a compliance function arrives with is what happens to its own obligations if it uses this. The answer is that the obligations do not move: the ecosystem is arranged so that identification, record keeping and monitoring happen in one place and are reusable by every product, rather than being re-implemented by each of them.
swss://control-layers4 layersEach layer can refuse, and no layer can be skipped
The group's Canadian entity holds a Money Services Business registration covering virtual currency services, payment service provision and foreign exchange. Regulated flows are operated through that entity and against its compliance programme, rather than through whichever company happened to build the product.
That choice has a cost, and the page would be dishonest without it. The obligations below apply to every launch they touch and slow some of them down. The alternative, claiming to be only software and routing around the requirement, was available and was not taken.
The obligations also set a floor for the rest of the ecosystem. Identity handling everywhere else is built to satisfy them, which is why verification is a layer rather than a form each product fills in differently.
Verifying who a party is before acting for them, to the standard the registration sets, with the verification recorded rather than asserted.
Retaining the record of each transaction and the identification behind it, for the period the regime requires.
Filing the reports the regime requires, on the schedule it requires them, from the entity that holds the registration.
Watching activity over time rather than checking once at onboarding, because a relationship changes after it begins.
The second half of each card matters more than the first. A control that cannot say no is a logging system, and the refusals below are the reason the ecosystem can be described as controlled rather than monitored.
Verification happens once, in one place, and is reusable by every product in the ecosystem. Business verification for an institution and individual verification for a member are performed by the identity layer, and the resulting credential is recorded on chain rather than kept as a file in whichever product collected it.
Keys stay with the party they belong to. The identity layer will refuse a session backed by a wallet whose key shares a vendor holds, which matters most where an institution is posting slashable collateral: a stake somebody else controls is not a stake, and a signature somebody else can produce is not consent.
What the chain will accept is decided by the chain. Finality is deterministic rather than probabilistic, so a settlement is final when its receipt is issued, and validator misbehaviour carries a slashing consequence enforced by protocol rather than by a policy somebody has to apply.
Administrative surfaces sit behind a Foundation session verified locally and the property's own path token. Missing or invalid either one returns 404 rather than 401, so a denied state cannot be distinguished from a route that does not exist, and probing yields nothing worth knowing.
A public ledger is a poor place for personal information, and nothing in this ecosystem puts it there. What settles on chain is a credential attesting that verification happened, not the material that produced it.
Identity data is collected by SWSS IVL and reused across the ecosystem. A product that needs to know a member is verified asks the identity layer rather than collecting documents of its own, which keeps the number of copies as low as the obligation allows.
The chain carries a credential attesting that verification took place. It does not carry the underlying documents, and nothing published to a public network identifies a member from the record alone.
An administrative session reaches administrative surfaces. It does not reach member holdings, and the identity layer remains the authority over what a given operator may see about a given party.
The group operates under four registrations, and local counsel is retained in each. The engineering standard does not vary by office, so a data subject is handled the same way wherever the work was carried out.
Systems are built against the control frameworks their sector requires, so a client's own audit finds the evidence it expects where it expects it. This is an engineering standard, stated as such, and not a claim that a certificate is held against each name below.
Architecture and security review happen against a written specification, by people who did not write it, before the work starts.
Automated verification blocks a release rather than warning about it, and no seniority opens the gate.
An incident carries a single named owner by role for its whole life, including the write up afterwards.
Every finding is recorded with what it means for the next environment, so a problem solved once is not rediscovered later.
A security page fails in one of two directions: vague claims that evidence nothing, or detail that helps somebody attack what is being described. Naming the second is the only way to be specific about the first.
None of this is withheld from a counterparty. Each entry says who can obtain it and on what basis, which is a different thing from publishing it to everybody who can type a URL.
Where systems run, how they are segmented and what sits between them is not published. A public map of an estate is useful to exactly one audience, and it is not the audience this page is written for.
available under agreement, to a counterparty's security functionThat keys are held in hardware and that every signature is logged is published. The procedure around ceremony, rotation and recovery is not, because the procedure is the part an attacker would plan against.
available in a due diligence process, under agreementWhich controls are implemented in which way, and what a given assessment found, belong in a review conducted with a named counterparty rather than on an open page where neither the context nor the remediation state travels with them.
available in a review, with scope agreedIncidents are owned, recorded and carried forward internally. What is shared externally is shared with the parties affected, in the form their own obligations require, rather than as a public narrative.
available to affected parties, as obligations requireThe separation that makes the control layers meaningful is structural. Four authorities own four domains, and reading the grid by column shows that each domain has exactly one owner.
| Authority | Identity who a party is | Custody moving what is held | Asset Records DEED-1 instruments | Block Production the validator set |
|---|---|---|---|---|
SWSS IVL Identity Authentication, KYC, KYB, credentials and signing. IVL holds no balance, stakes nothing and bridges nothing: it establishes who a party is and signs what that party approves. | owns | |||
SWSS App Custody & Treasury Wallet operations, staking, treasury movement and bridging. Everything a member's holdings do happens here, under the identity IVL has established and never inside it. | owns | |||
SWSS RWAX Deed & Exchange Data The DEED-1 instruments, their records and the exchange data around them. Asset truth is owned here and nowhere else in the ecosystem. | owns | |||
SWSS NodeX Validator Operations Validator onboarding, the operating set and the parameters that govern it. Who may produce a block is decided in one place, on the record. | owns |
This is why an administrative credential cannot be escalated into access to holdings: the systems that establish who somebody is and the systems that move what they hold are different systems, with different codebases and different authorities.
Five policies and a specification. Where this page summarises and a policy states, the policy governs, and a summary that disagrees with it is a defect in the summary.
Due diligence material that is not published here is provided to a counterparty under agreement. The desk at the foot of this page reaches counsel directly.
Due diligence material, regulatory questions and the detail a counterparty's own compliance or security function needs before contracting, routed to counsel in the relevant jurisdiction.
For due diligence requests, regulatory questions, and the material a counterparty's compliance or security function needs before contracting. Routed to counsel in the relevant jurisdiction.
Due Diligence
Material provided under agreement
Four Jurisdictions
Counsel retained in each
Handled In Confidence
No distribution beyond the desk
Direct Contact
[email protected]This page describes how the ecosystem is arranged and is published for information only. It is not legal, regulatory or compliance advice, and it does not relieve any party of its own obligations.
Framework alignment described above is an engineering standard and is not a representation that a certification is held against each framework named. The Money Services Business registration is held by the group's Canadian entity, and nothing here extends it to any other entity or activity.
Where this page and a published policy differ, the policy governs. Before relying on anything above, read the AML and KYC Policy, the Risk Disclosure and the Terms of Service, and take your own professional advice.