The same identity. A connected account.
Bankeiz admits an existing Receiz identity and supported account state. Payments, Settlement and financial operations retain their own review and authority.
Implemented reference: BankeizExplore bankingRECEIZ IDENTITY CONTINUITY
Your identity
shouldn’t start over.
You already have an identity.
Bring it anywhere.
Authentication opens the door. Continuity brings your existing identity and supported history with you.
Built. Implemented. Independently inspectable.
Representative identity · Illustrative architecture
THE SAME YOU. SOMEWHERE NEW.
Open another application.
Continue as yourself.
Receiz and Bankeiz are distinct applications. The identity in this demonstration stays exactly the same. Try the visual, then open the actual application separately.
ReceizEstablished account
Alex · Representative identityalex.receiz.id
- Verified account binding
- Supported portable history
- Ownership records + recovery
Original identity. Original sources.
BankeizIndependent application
A new place.
Your existing identity.
Continue with the Receiz identity you already hold.
Original Receiz ID recognizedalex.receiz.id
- Existing account restored
- Bankeiz session established
- No new underlying identity
Demonstrated result · Separate app permissions
See what changes. And what stays.Face ID / Passkey authentication · IllustratedThis visual does not invoke biometrics or establish a session.
BEYOND THE SIGN-IN
The internet solved login.
It didn’t solve continuity.
Passkeys make authentication simpler. Federation can connect sign-in across domains. Portable, verified application state solves another problem: what you can continue with after you enter.
Conventional application model
- Authenticate.
- Create or map an application account.
- Retrieve that application’s own records.
- Repeat in another application.
Receiz identity continuity
- Authenticate.
- Recognize the established Receiz identity.
- Admit compatible verified account and proof state.
- Establish application-specific authorization.
- Continue from supported history.
Knowing who signed in is not the same as preserving who they already were.
THE ARCHITECTURE
One identity.
Distinct applications.
Continuous history.
Six connected layers, with a clear job for each. Open a layer to inspect its boundary.
Inspect the related origins01Receiz IDThe identity stays yours.
+
The identity stays yours.
A persistent Receiz identity and its verified account bindings connect supported records to their original authority. A username helps people recognize you; the admitted identity proof establishes the binding.
02Passkey and presenceYou prove it’s you.
+
You prove it’s you.
The established WebAuthn ceremony requests user verification through a supported device: Face ID, Touch ID, a device PIN or another supported authenticator. PBI does not bypass WebAuthn origin or RP restrictions.
03Canonical Receiz realmOne explicit passkey realm.
+
One explicit passkey realm.
The canonical production RP ID is receiz.com. Receiz’s Related Origins implementation explicitly authorizes bankeiz.com and www.bankeiz.com through WebAuthn Related Origin Requests, where the browser supports them.
04Portable proof and recoveryRestore from admitted originals.
+
Restore from admitted originals.
Identity Records, Identity Seals and Receiz Keys carry the supported recovery and verified account state. The verifier admits the stronger original first; an application projects only the state its supported contracts understand.
05Application sessionsA different application keeps its own rules.
+
A different application keeps its own rules.
Receiz and Bankeiz establish their own authorized application access. Proof admission, session issuance and action consent remain separate operations. Recognizing an identity does not grant every permission.
06Proof-native continuityThe source stays connected.
+
The source stays connected.
Supported identity, ownership, custody and history stay attached to their verified sources. Later synchronization can add verified records; it cannot replace stronger admitted proof with a weaker session or display.
OPEN IMPLEMENTATION
Don’t take our word for it.
Inspect the source.
These are implemented primitives and their actual source paths. Code explains the implementation. Tests, deployment evidence and physical-device qualification answer different questions.
RECEIZ → BANKEIZ
A different domain.
The same identity.
The owner reports opening Bankeiz on a mobile device, authenticating with Face ID and recovering the established Receiz account while remaining inside Bankeiz.
User-reported mobile experience. The visual above is an illustration, not a screen recording of that event.
What the retained evidence establishes
- Implementation
- Canonical Receiz RP and explicitly authorized WebAuthn Related Origin Requests, with native Bankeiz proof admission and account recovery.
- Automated qualification
- Source, signature and virtual-authenticator checks are recorded with the integration work. They are not a physical-device test.
- Live policy
- The origin activation record establishes allowed-origin behavior for Bankeiz and verifier service health.
- Exact boundary
- The activation record does not independently qualify a physical iPhone or establish deployment of every integration component.
WHAT CONTINUITY ENABLES
Identity is the beginning.
Keep what comes with it.
Different applications can provide different experiences while supported identity and original proof remain connected. Every integration keeps its own admission and authorization boundaries.
An original can outlive one experience.
Receiz and Wildz carry proof-native ownership and supported asset history. Another game must explicitly integrate the same verification and admission contracts.
Implemented foundation; third-party games integrate explicitlyExplore gamingKeep the evidence after the purchase.
Original proof objects carry supported provenance, ownership and transaction evidence beyond one merchant’s display. A new merchant still defines its accepted instruments and permissions.
Implemented proof and receiving contractsExplore commerceOne participant. Distinct relationships.
Independent organizations can recognize the same identity while keeping memberships, permissions and commercial agreements separate. Each organization’s integration must be qualified.
Implemented identity; organization-specific integration requiredExplore cooperativesOne agent. Your context. A connected next step.
Continue with the same agent, Receiz identity and supported conversation context across compatible applications and authorized tools. Pick up with the person, the conversation and the next step connected, without repeating setup. Consequential actions still require bounded human authorization.
Implemented agent and identity primitives; compatible-app integration and tool permissions requiredExplore ai agentsA lost session is not a lost identity.
Admit an Identity Record, Identity Seal or Receiz Key to restore its supported account state. Keep original files private. Identity recovery does not clone protected offline Note custody.
Implemented recovery and proof admissionExplore recoveryFOR DEVELOPERS
Stop rebuilding identity.
Build what your app does.
Published Receiz v129 infrastructure provides identity admission, account recovery, proof-native state, ownership and authority, verified artifacts and history. Compose the SDK, MCP tools and AI Skills within their supported contracts.
Start with the original artifact. Verify it. Admit its identity proof. Establish your application’s authorized access separately.
Build with ReceizPublished SDK · v129Installation guide
npm install @receiz/sdk@129.0.0import {
verifyReceizArtifact,
createReceizArtifactAdmissionEngine,
} from '@receiz/sdk';
// recordBytes and passphrase are supplied
// by the person opening their original.
const proof = await verifyReceizArtifact(recordBytes);
const admit = createReceizArtifactAdmissionEngine();
const identity = await admit(proof, {
profile: 'identity',
identityPassphrase: passphrase,
});
if (identity.verdict !== 'canonical-identity') {
throw new Error('Identity proof not admitted');
}
// Admission is not payment permission.Supported SDK calls, as composed in Bankeiz. This excerpt verifies and admits proof; it does not issue an application session or authorize a financial action.
TRUST AND AUTHORIZATION
Portable identity.
Explicit access.
Your identity can be recognized without giving every application permission to do everything.
The realm stays enforced.
The canonical Receiz RP ID remains enforced. Only explicitly authorized related origins can use the corresponding WebAuthn mechanism.
Every ceremony must verify.
The applicable challenge, origin, RP, signature, user-verification and credential-binding requirements still apply. PBI does not bypass browser domain rules.
Every action has its own authority.
A verified identity does not authorize a payment, ownership transfer or access to private data. Each application retains its consent and authorization rules.
Recovery and sync have different jobs.
Proof admission, local identity recovery, online session issuance and global synchronization remain separate. A session is not the original identity proof.
What if my browser doesn’t support Related Origin Requests?
Use a supported authentication or recovery path, such as opening an admitted original Identity Record where available. Related Origin Requests support depends on the browser and authenticator. This page does not claim universal browser support or unrestricted cross-domain passkey use.
FOR INSTITUTIONS AND PLATFORMS
Recognize the person.
Keep the policy.
Build interoperable identity without merging organizations’ permissions. Banks, platforms and cooperatives can recognize an established participant while retaining their own admission, consent, membership and commercial rules.
- Identify the supported records. State exactly which proofs and account projections your application admits.
- Qualify the integration. Test the deployed origins, supported browsers, recovery paths and refusal behavior.
- Authorize each operation. Keep private-data access, payments, ownership transfer and custody under their existing contracts.
VALUE WITH ITS CONTINUITY
Your identity should follow you.
So should the value you own.
Bankeiz demonstrates financial integration. Receiz and Wildz carry proof-native gaming and ownership. Other developers can build compatible applications, admitting supported identity and records without separating them from their source.
This does not make every application’s private database or proprietary content portable. It preserves the original truth the receiving application can actually verify and admit.
The application changes.The underlying person doesn’t.
REALITY-GRADE INFRASTRUCTURE
Another application.
Already yourself.
Your identity is not the website you’re visiting.
The infrastructure exists. Experience it. Inspect it. Build with it.