Accept the money. Keep it moving. | Reality-Grade Banking
https://bankeiz.com/accept/

See the difference between a payment notification and independently verifiable financial value. Explore receiving, ownership and onward payments through working demonstrations.

Skip to content (https://bankeiz.com/accept/#main)

(https://bankeiz.com/learn/)
How it works (https://bankeiz.com/learn/#how-it-works)Business (https://bankeiz.com/business/)Guides (https://bankeiz.com/learn/#guides)
Enter bank  (https://bankeiz.com/)

Reality-Grade Banking
Built on Receiz  (https://bankeiz.com/accept/#developers)

ACCEPT THE MONEY.

NOT JUST THE

PAYMENT NOTIFICATION.

A payment provider tells your business a payment happened. Reality-Grade Banking delivers the financial Original, its ownership, its source and the evidence necessary to verify and transfer it.

Receive it. Verify it.

Use it. Pass it on.
See the difference (https://bankeiz.com/accept/#difference)Explore the receiving standard (https://github.com/kojibai/reality-grade-banking/blob/main/institution/receiving-standard.md)

Provider integration

Customer

Payment

provider

Merchant

Payment confirmed $250.00

The result arrives through the service.
Connected to a provider.

Proof-native integration

Customer

Financial

Original

Independent

receiver

SourceIdentityAuthorityOwnershipValueContinuity

The value arrives with its evidence.
Connected to the value itself.

This is a different architecture for what happens after payment.Scroll to experience it ↓ (https://bankeiz.com/accept/#difference)

Illustration: two proof objects remain connected through one transfer and its source layers. (https://bankeiz.com/art/proof-transfer.webp)

01 / Same payment. Different architecture.

What happens

after payment?

A restaurant receives $250. Follow the same commercial transaction through two different receiving systems.

Deterministic demonstration · No money moves

01020304
Play the story 

Traditional provider integration

Customer Provider Merchant
Supported infrastructure & settlement

Payment initiated
Customer pays

A supported payment method starts a $250 payment.

Reality-Grade Banking

OriginalSource · ownership · continuity
RestaurantIndependent supplier

Original offered
Customer pays

A legitimate $250 proof-native payment is initiated.

Same commercial purpose. Different receiving architecture.

Provider integration:You received a payment through a service.

Proof-native integration:You received independently verifiable financial value.

Conventional systems establish financial ownership, accounting records and legal settlement. Services and rails differ. This comparison concerns proof portability and independent receiving.

02 / The useful difference

THE SECOND PAYMENT

CHANGES EVERYTHING.

The first payment gets value into the merchant’s hands. The second payment reveals the architecture.

A restaurant receives $250. It pays its supplier $180. The supplier pays its distributor $120. The distributor pays a contractor $70.

Each recipient independently verifies the necessary evidence and accepts the next ownership state. The original payment provider is not required to authorize every subsequent proof-native transfer.

Deterministic demonstration · No money moves
RestaurantRestaurant till$250SupplierIndependent receiver$180DistributorBusiness application$120ContractorAnother wallet$70

AdmissionRestaurant → SupplierSupplier → DistributorDistributor → Contractor

Selected recipient
Restaurant

$250 received

Source

Demonstration admission · $250 Reserve denomination

Predecessor

Demo admission

Recipient

Restaurant · its own receiving implementation

Accepted state

Initial state in the demonstration

Verification result

Demonstration invariants satisfied; no live proof verified

One source lineage. Multiple legitimate transfers.

Independent receiving. Continuous proof.

Less work between payments

The value is ready

for its next use.

Keep the evidence instead of reconstructing the story. Reuse the receiving contract instead of creating a separate proof system for every application.

One carried sourceReceive → Verify → Accept

Next authorized payment

Another independent receiverSame necessary evidence.

Less custom integration. Less history reconstruction. A clearer path to the next payment.
Actual time, fees and operating costs depend on the implementation and rail. No numerical savings are assumed.

03 / The network grows through relationships

KNOW THEIR EMAIL?

YOU CAN PAY THEM.

Your supplier does not need a Bankeiz username for you to start with their email. The invitation brings them to the receiving steps.

They already have a reason to receive the payment. The invitation opens the verified recipient’s account with its recorded funds. Their next payment follows that account’s supported financial contract.
Deterministic demonstration · No money moves
This is a demonstration of recorded-account email payments and a verified Bankeiz handoff. It sends no email and creates no account or payment. Native proof receiving is a separate financial operation.

1. Send2. Invitation3. Receive4. Use it

BankeizInteractive example

Send payment
Pay your supplier.
RecipientAmountPurposeSend payment Demonstration only · no money moves

An email delivers the invitation. It is not an ownership credential.

Identity establishes authority.
The recorded-account route commits payment to the legitimate recipient account before sending the invitation. The verified handoff opens that same account; it does not credit the payment again. Invitation expiry governs access to the link, not cancellation of the recorded payment. Independent native receiving must satisfy its own custody and consumption contract. Read the receiving requirements (https://github.com/kojibai/reality-grade-banking/blob/main/institution/receiving-standard.md)

04 / Open the evidence

NOT JUST A NUMBER.

THE EVIDENCE BEHIND IT.

The balance is what you see. The Original establishes what it means.

Payment received$250.00 Accepted in this demonstration

Financial OriginalIts evidence stays connected.

Deterministic demonstration · No money moves

The card is a teaching view of the contract. It is not a sealed payment record or spendable source.

01Source

The exact enclosing Original, its admitted value source and canonical trust bindings.
sourceProofObjectId · sourceValueHead · pinned rootsInspect the actual contract (https://github.com/kojibai/reality-grade-banking/blob/main/institution/digital-payments.md)

02Identity & authority

The receiving subject and application are bound to the operation. Signing consent belongs to the authorized participant.
applicationId · destinationSubjectId · participantIdInspect the actual contract (https://github.com/kojibai/reality-grade-banking/blob/main/institution/receiving-standard.md)

03Ownership

Current source and destination heads must match the actual participants. An account login or a plan alone does not transfer ownership.
expectedParticipantHeads · expectedDestinationHeadInspect the actual contract (https://github.com/kojibai/reality-grade-banking/blob/main/institution/digital-payments.md)

04Temporal authority

KaiSigil-bound KKS evidence establishes legitimate causal ordering. A local timestamp is a display, not temporal authority.
Verified KaiSigil-bound KKS coordinatesInspect the actual contract (https://github.com/kojibai/reality-grade-banking/blob/main/institution/receiving-standard.md)

05Funding composition

Reserve preserves its original funded dollar denomination. Settlement preserves its exact native Phi amount. Mixed Notes carry every funding part.
Explicit rail · amountPhiMicro · Note fundingPartsInspect the actual contract (https://github.com/kojibai/reality-grade-banking/blob/main/docs/settlement-note-contract.md)

06Continuity

The exact predecessor, committed participant transitions and canonical recovery are retained for the next authorized operation.
transitionSet · committedTransitions · canonical recoveryInspect the actual contract (https://github.com/kojibai/reality-grade-banking/blob/main/institution/holding-and-recovery.md)

07Verification

Check authenticity, current authority and the accepted transition separately. An inspection report cannot mint spend authority.
verifyTransitionSet → qualified commit → receiveReserve / receiveSettlementInspect the actual contract (https://github.com/kojibai/reality-grade-banking/blob/main/institution/receiving-standard.md)

AuthenticityCurrent authorityAccepted transition
Three distinct checks. A genuine Original is not automatically available to spend.

05 / One standard. Independent implementations.

YOU DON’T NEED BANKEIZ.

YOU NEED TO CONFORM.

Bankeiz is a reference financial application. Receiz provides the proof infrastructure. Reality-Grade Banking defines the receiving requirements.

Financial OriginalSource · ownership · continuity

BankeizIndependent receivingIndependent bankIndependent receivingMerchant checkoutIndependent receivingBusiness paymentsIndependent receivingIndependent walletIndependent receivingInstitutional receiverIndependent receiving

Bankeiz implements the receiving requirements. The Original is the center of the architecture.

Another developer can build another application. Another institution can build another receiving system. They do not need to copy Bankeiz’s interface or operate on Bankeiz servers.

Each must preserve the necessary evidence and satisfy the applicable authority, ownership, custody and continuity requirements. Qualification applies to the exact capability, build and operating environment.

Different applications. Same necessary evidence.

Independent verification.

06 / For developers

INTEGRATE THE RECEIVING STANDARD.

NOT ANOTHER WALLED GARDEN.

Your application becomes a conforming receiver of independently verifiable financial value. The installed SDK already provides the verification and edge-value primitives.

01Receive the Original or supported handoff.

02Open the exact proof object.

03Verify source and integrity under pinned trust.

04Verify identity, authority and exact consent.

05Check ownership and predecessor continuity.

06Evaluate custody, consumption and conflicts.

07Accept all required transitions atomically.

08Preserve exact sources and canonical recovery.

09Use the accepted current head for the next authorized payment.

SDK receiving boundaries@receiz/sdk · 129.0.0

import type {ReceizClient} from '@receiz/sdk';

type Edge=ReceizClient['value']['edge'];
type AdmittedInput=Parameters<Edge['planReserve']>[0];
type CommittedRecoveryInput=Parameters<Edge['createRecovery']>[0];

// The host supplies admitted sources and binds the exact amount, rail,
// participant heads, application and consent. A plan is not a payment.
export async function inspectBothReceivers(edge:Edge,input:AdmittedInput){
const wrapper=await edge.planReserve(input);
await edge.inspect(wrapper.plan,{
participantId:wrapper.sourceParticipantId,expectedRail:'reserve',
});
await edge.inspect(wrapper.plan,{
participantId:wrapper.destinationParticipantId,expectedRail:'reserve',
});
return wrapper;
}

export async function prepareExactTransition(edge:Edge,set:unknown,applicationId:string){
const verified=await edge.verifyTransitionSet(set,{audience:applicationId});
return edge.prepareCommitSet(verified);
}

// Between preparation and recovery, the qualified host store must atomically
// commit ALL participants or NONE and retain real SDK-issued custody.
// No generic SQL callback or caller-created object can replace that boundary.
export async function receiveActuallyCommittedValue(
edge:Edge,committed:CommittedRecoveryInput,senderParticipantId:string,receiverParticipantId:string,
){
const recovery=await edge.createRecovery(committed);
// The host must durably retain this exact recovery before confirmation.
// These fragments expose SDK boundaries, not a complete host adapter.
await edge.confirmReserveSend(recovery,{
applicationId:committed.applicationId,
participantId:senderParticipantId,
});
return edge.receiveReserve(recovery,{
applicationId:committed.applicationId,participantId:receiverParticipantId,
});
}

Three type-checked SDK fragments. The host first admits the exact sources and creates the authorized transition set through the canonical source and signing workflow. It then supplies qualified all-participant atomic commit custody and durably retains canonical recovery. A JSON receipt or database response cannot replace those boundaries. Settlement uses the corresponding explicit Settlement methods.

Receiz developers (https://receiz.com/developers)SDK package (https://www.npmjs.com/package/@receiz/sdk)Open-source implementation (https://github.com/kojibai/reality-grade-banking)Receiver profile (https://github.com/kojibai/reality-grade-banking/blob/main/institution/receiver-profile.json)Conformance workspace (https://bankeiz.com/conformance/)Offline verifier (https://bankeiz.com/verify/)Receiver qualification (https://github.com/kojibai/reality-grade-banking/blob/main/institution/qualification.md)

The SDK capabilities are implemented. An institution must integrate and qualify its own custody and receiving environment; the published reference profile does not award an institution a production conformance badge.

07 / The business decision

A PAYMENT METHOD IS NOT

A FINANCIAL ARCHITECTURE.

How the receiving architectures differ
The questionTraditional provider integrationReality-Grade Banking integration

What is integrated?A provider’s payment services and network.Published proof-native receiving requirements.

What is received?A payment result and value under the service’s settlement arrangement.The financial Original and its accepted ownership transition.

Who verifies?The provider and participating financial infrastructure.A conforming receiver checking the necessary evidence.

Where is the history?Provider, banking and accounting records.Proof-native continuity preserved with the Original and recovery.

Can another implementation receive?Through the supported services, integrations and rails.Through its own implementation of the receiving contract.

What happens after payment?Funds are used through the financial rails available to the merchant.Accepted native value can move onward under its proof-native rules.

What does the merchant depend on?The capabilities, balances and settlement arrangements of its services.The accepted Original, qualified custody and applicable receiving and consumption rules.

Who defines the integration?The provider’s supported integration contract.Published, independently implementable receiving requirements.

The difference is what the recipient

can do with the value afterward.

08 / A complete restaurant example

WATCH AN ECONOMY CONTINUE.

The customer pays $100 once. Follow five onward payments and see where every dollar remains. No value is counted twice.

Deterministic demonstration · No money moves
Simple viewProof view

Restaurant$100Remaining balance

Produce supplier$0Remaining balance

Wholesaler$0Remaining balance

Distributor$0Remaining balance

Contractor$0Remaining balance

Next merchant$0Remaining balance

AdmissionTransfer 1Transfer 2Transfer 3Transfer 4Transfer 5

Customer → Restaurant$100 received
The initial value is held by the restaurant.

← PreviousPayment 0 of 5Pay supplier $60 

$100 total value held across all six participants · counted once

The customer paid once.

The value kept working.

09 / Institutional adoption

BANKS CAN PARTICIPATE.

THEY DON’T HAVE TO CONTROL THE NETWORK.

A bank can implement the receiving standard. A merchant can operate its own receiver. A software company can build its own proof-native wallet.

01
Independent bank

Verify → accept → preserve → transfer

02
Merchant receiver

Verify → accept → preserve → transfer

03
Software wallet

Verify → accept → preserve → transfer

The network grows through conformance,

not permission.

No Bankeiz authorization hub is required for every proof-native transition. Each participating receiver must meet the applicable receiving and qualification requirements.

10 / Funding and circulation

THE ENTRANCE

IS NOT THE DESTINATION.

An eligible conventional payment can introduce funding. The admitted proof-native value can then continue through legitimate transfers without recreating that original fiat payment.

Fiat entranceEligible funding rail

Admitted valueVerified source & allocation

RestaurantSupplierIndependent recipientIndependent circulation ↗

The funding source remains part of the provenance. It does not have to operate every future exchange. The applicable receiving contract governs ownership, exact denomination and each accepted transfer.

Card funding can be reversed. A later reversal remains evidence with applicable financial obligations; it does not automatically rewrite completed native transfer history. This architecture is not a general promise that each holder can demand the original fiat from Bankeiz.

11 / Beyond checkout

PAYMENTS WERE THE ENTRANCE.

PORTABLE VALUE IS THE DIFFERENCE.

01Accept a payment.
A provider connects a transaction to its services and supported network.

02Receive the Original.
The receiver verifies the source, accepts ownership and keeps the evidence.

03Keep it moving.
Another conforming implementation accepts the next legitimate transition.

Reality-Grade Banking

DON’T JUST ACCEPT PAYMENTS.

ACCEPT THE VALUE ITSELF.

Verify its source. Establish its ownership. Preserve its history. Transfer its value. Pay your suppliers, pay your contractors and connect independent applications.

Start accepting proof-native payments (https://github.com/kojibai/reality-grade-banking/blob/main/institution/README.md)Explore the Receiz SDK (https://receiz.com/developers)View the open-source implementation (https://github.com/kojibai/reality-grade-banking)
Deterministic demonstration · No money moves

0102030405
Play the story 

Financial OriginalSource · ownership · continuity

CustomerAuthorizes paymentRestaurantIndependent implementationSupplierIndependent implementationDistributorIndependent implementationNext recipientIndependent implementation

Independent bankMerchant applicationAnother walletInstitutional receiver

A customer initiates a legitimate payment. Follow the evidence through the next recipients.

CustomerRestaurantSupplierDistributorNext recipient

THE MONEY MOVES.

THE PROOF REMAINS.

THE ECONOMY CONTINUES.

One receiving standard. Independent implementations.

Value that carries its own proof.

REALITY-GRADE BANKINGBuilt on Receiz. Implemented through Bankeiz.

Open to independent conformance.

(https://bankeiz.com/icon.svg)Bankeiz (https://bankeiz.com/)
Proof-native economy.

Reality-grade banking.

Reality-grade infrastructure.

For you

People & families (https://bankeiz.com/for/people/)

Businesses (https://bankeiz.com/for/businesses/)

Independent work (https://bankeiz.com/for/independent-work/)

Creators (https://bankeiz.com/for/creators/)

Communities (https://bankeiz.com/for/communities/)

Institutions (https://bankeiz.com/for/institutions/)

Public finance (https://bankeiz.com/for/public-finance/)

Platforms & developers (https://bankeiz.com/for/platforms/)

Banking

Your account (https://bankeiz.com/)

See banking in action (https://bankeiz.com/banking/)

User guide (https://bankeiz.com/guide/)

Find your fit (https://bankeiz.com/fit/)

Cooperative economy (https://bankeiz.com/coops/)

Your Vaults (https://bankeiz.com/vaults/)

Protect your value (https://bankeiz.com/protect/)

Payment fraud (https://bankeiz.com/fraud/)

Recover your identity (https://bankeiz.com/recover/)

Begin with your source (https://bankeiz.com/start/)

Banking explained (https://bankeiz.com/learn/)

Payments (https://bankeiz.com/learn/payments/)

Get paid (https://bankeiz.com/get-paid/)

Your Counter (https://bankeiz.com/merchant/)

Payment requests (https://bankeiz.com/learn/payment-requests/)

Deposits (https://bankeiz.com/deposit/)

Notes (https://bankeiz.com/learn/notes/)

Your agent (https://bankeiz.com/agent/)

Messages & agent (https://bankeiz.com/learn/messages/)

Your Twin (https://bankeiz.com/your-twin/)

Calendar & appointments (https://bankeiz.com/book/)

Meetings (https://bankeiz.com/meet/)

Business in action (https://bankeiz.com/action/)

Receiz ID (https://bankeiz.com/learn/receiz-id/)

Identity continuity (https://bankeiz.com/id/)

Assets

Explore assets (https://bankeiz.com/explore/)

Open the proof (https://bankeiz.com/proof/)

Your moments, your value (https://bankeiz.com/moments/)

Proof objects & ownership (https://bankeiz.com/learn/proof-objects/)

Digital Matter (https://bankeiz.com/matter/)

Create an asset (https://bankeiz.com/learn/creating-an-asset/)

Ownership (https://bankeiz.com/learn/ownership/)

Fractional ownership (https://bankeiz.com/learn/fractional-ownership/)

Physical assets (https://bankeiz.com/learn/physical-assets/)

Rights & backing (https://bankeiz.com/learn/asset-rights-and-backing/)

Crypto holdings (https://bankeiz.com/crypto/)

NFTs & collections (https://bankeiz.com/nfts/)

Music & audio (https://bankeiz.com/explore/music/)

Images & photography (https://bankeiz.com/explore/images/)

Videos & film (https://bankeiz.com/explore/videos/)

Books & publishing (https://bankeiz.com/explore/books/)

Essays & research (https://bankeiz.com/explore/essays/)

Recorded moments (https://bankeiz.com/explore/moments/)

Collectibles (https://bankeiz.com/explore/collectibles/)

Documents (https://bankeiz.com/explore/documents/)

Markets

The existing economy (https://bankeiz.com/economy/)

Asset market (https://bankeiz.com/market/)

Buying ownership (https://bankeiz.com/market/buy/)

Selling a position (https://bankeiz.com/market/sell/)

Prices & valuations (https://bankeiz.com/market/value/)

Ownership & rights (https://bankeiz.com/market/ownership/)

Costs & liquidity (https://bankeiz.com/market/costs/)

Trade records (https://bankeiz.com/market/history/)

Accept payments (https://bankeiz.com/accept-payments/)

Together (https://bankeiz.com/together/)

Global Market Cap (https://bankeiz.com/market-cap/)

How value works (https://bankeiz.com/learn/how-value-works/)

Settlement & Reserve (https://bankeiz.com/learn/reserve-and-settlement/)

Circulation & listings (https://bankeiz.com/learn/circulation/)

Value over time (https://bankeiz.com/learn/price-history/)

History

Public Ledger (https://bankeiz.com/ledger/)

Transaction receipts (https://bankeiz.com/learn/receipts/)

Source of funds (https://bankeiz.com/learn/source-of-funds/)

Memory Crystals (https://bankeiz.com/learn/memory-crystals/)

Time & ordering (https://bankeiz.com/learn/time-and-ordering/)

Account verification (https://bankeiz.com/verify/)

Standards & technology

Proof-native economy (https://bankeiz.com/learn/proof-native-economy/)

Trust & authority (https://bankeiz.com/trust/)

Value & its source (https://bankeiz.com/money/)

The standard in practice (https://bankeiz.com/in-practice/)

About the standard (https://bankeiz.com/about/)

Documentation (https://bankeiz.com/docs/)

Proof-native standards (https://bankeiz.com/standards/)

Conformance (https://bankeiz.com/conformance/)

Institution integration (https://bankeiz.com/institutions/)

Developer reference (https://bankeiz.com/developers/)

SDK schemas & reference (https://bankeiz.com/schemas/)

Security & authority (https://bankeiz.com/learn/security/)

Releases & qualification (https://bankeiz.com/releases/)

Bankeiz · Reality-Grade Banking (https://bankeiz.com/learn/reality-grade-banking/)
Help (https://bankeiz.com/help/)Costs (https://bankeiz.com/fees/)Privacy (https://bankeiz.com/privacy/)Use & responsibilities (https://bankeiz.com/terms/)All guides (https://bankeiz.com/learn/guides/)Questions (https://bankeiz.com/learn/questions/)Glossary (https://bankeiz.com/learn/glossary/)Account access (https://bankeiz.com/learn/account-access/)Signing key (https://bankeiz.com/learn/signing-key/)License & notices (https://bankeiz.com/legal/)Open source (https://github.com/kojibai/reality-grade-banking)
Public source directories
All public Originals — https://bankeiz.com/read/catalog/
Retained public Ledger — https://bankeiz.com/read/ledger/