Loading...
DOCUMENTATION
INTERLOCC Protocol
Executive Overview
A comprehensive overview of the INTERLOCC Protocol's business capabilities, workflows, security model, and operational features. This document provides a clear understanding of the protocol without exposing implementation details.
Capital Efficiency
60-90%
Settlement Reduction
Payment Speed
Instant
Provisional Credit
Settlement Rails
4
SWIFT, ERC20, Bridge, RFQ
INTERLOCC Protocol
Executive Overview
Version 1.2 Document Date: January 2026 Classification: Client Distribution
Executive Summary
The INTERLOCC Protocol (Interbank Liability Obligation & Clearing Coordination) is a next-generation interbank payment clearing and settlement infrastructure that combines the security and compliance requirements of traditional banking with the efficiency and transparency of blockchain technology.
Key Value Propositions
Capital Efficiency Through Multilateral Netting INTERLOCC reduces settlement volume by 60-90% through intelligent multilateral netting, significantly decreasing the capital required for nostro/vostro account funding and reducing settlement risk exposure.
Instant Liquidity with Deferred Settlement Beneficiaries receive immediate provisional credit upon transaction authorization, while banks settle net positions in periodic batches (hourly, daily, or custom windows), optimizing both customer experience and operational efficiency.
Privacy-Preserving Architecture End-customer identities remain pseudonymous at the protocol layer, with only bank-level exposure during settlement. Full KYC/AML compliance is maintained through off-chain processes and on-chain attestation.
Multi-Rail Settlement Flexibility The protocol supports multiple settlement mechanisms including traditional SWIFT transfers, on-chain stablecoin movements, cross-chain bridges, and request-for-quote (RFQ) liquidity provision, ensuring operational resilience and cost optimization.
Comprehensive Audit Trail Every state transition, authorization decision, and settlement action is recorded immutably, providing regulatory compliance, dispute resolution capabilities, and full transaction traceability.
Business Impact
- Reduce Settlement Costs: Lower transaction fees through batch processing and rail optimization
- Improve Capital Efficiency: Free up capital trapped in pre-funded accounts
- Accelerate Payment Speed: Instant beneficiary credit versus traditional T+1/T+2 settlement
- Enhance Risk Management: Real-time bilateral exposure monitoring with automatic limit enforcement
- Ensure Regulatory Compliance: Built-in screening checkpoints and comprehensive audit logging
- Maintain Operational Control: Granular role-based permissions with emergency safeguards
Table of Contents
- Protocol Overview
- Functional Architecture
- Payment Lifecycle
- End-to-End Workflows
- Actor Roles & Capabilities
- On-Chain Transparency
- Security & Governance Model
- Operational Visibility
- Glossary
Protocol Overview
Business Problem
Traditional interbank payment systems face several fundamental challenges:
- Capital Inefficiency: Banks must maintain significant pre-funded positions (nostro accounts) with correspondent banks, tying up billions in non-productive capital
- Settlement Lag: Standard settlement cycles (T+1, T+2) delay beneficiary access to funds, impacting customer satisfaction and business operations
- Bilateral Settlement: Each bank pair settles independently, missing opportunities for multilateral netting
- Limited Transparency: Opaque settlement processes complicate reconciliation, dispute resolution, and regulatory reporting
- Single Point of Failure: Dependency on a single settlement rail creates operational risk
INTERLOCC Solution
INTERLOCC introduces a four-phase operating model that transforms how banks coordinate cross-border and domestic payments:
Phase 1: Authorization & Locking
When a payment is initiated, the sending bank locks the required funds in escrow and obtains cryptographic proof of custody. This proof is validated by independent attestors (trusted third parties), ensuring the payment is fully backed before any liability is created.
Phase 2: Compliance & Screening
The receiving bank performs required AML/KYC screening on the transaction. Only after explicit approval does the payment proceed. Automated timeout mechanisms ensure payments cannot remain indefinitely in screening limbo.
Phase 3: Liability Creation & Provisional Credit
Upon screening approval, an Interbank Liability Obligation (ILO) is created, representing a formal debt from the sending bank to the receiving bank. The receiving bank immediately issues provisional credit to the beneficiary, backed by this ILO. Customers experience instant payment receipt, while banks defer actual settlement.
Phase 4: Netting & Final Settlement
Periodically (e.g., every 6 hours), banks participate in multilateral netting windows. The protocol calculates net positions across all outstanding ILOs, dramatically reducing the number and size of required settlements. Settlement executors then transfer the net amounts via the most cost-effective rail, and the protocol finalizes all covered obligations atomically.
Operating Model
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Bank A │ │ INTERLOCC │ │ Bank B │
│ │ │ Protocol │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
│ 1. Lock funds │ │
│──────────────────────>│ │
│ │ │
│ 2. Submit proof │ │
│──────────────────────>│ │
│ │ 3. Screen payment │
│ │<──────────────────────│
│ │ │
│ 4. Issue ILO │ 4. Credit customer │
│──────────────────────>│──────────────────────>│
│ │ │
│ [Netting Window] │ │
│ │ │
│ 5. Calculate net │ │
│<─────────────────────>│<─────────────────────>│
│ │ │
│ 6. Settle net amount │ │
│<═══════════════════════════════════════════════│
│ │ │
│ 7. Finalize & release │ │
│──────────────────────>│──────────────────────>│
│ │ │
Key Differentiators
Programmable Compliance: Screening and approval requirements are enforced at the protocol level, not left to voluntary adherence.
Cryptographic Custody Proof: Payments cannot proceed without verifiable proof that funds are escrowed, eliminating unsecured credit risk.
Bilateral Credit Management: Banks set mutual credit limits per currency, with real-time utilization tracking preventing overexposure.
Atomic Settlement: All payments in a settlement batch are finalized together or none at all, preventing partial settlement failures.
Operational Flexibility: Banks retain control over screening timelines, netting participation, and settlement rail selection within protocol-defined guardrails.
Functional Architecture
The INTERLOCC Protocol is organized into four functional layers, each providing essential business capabilities:
Layer 1: Foundation & Registry
This layer provides the governance, access control, and configuration infrastructure that underpins the entire system.
Bank Registry
Maintains the authoritative directory of all participating financial institutions. Each bank registers with identifying information (name, BIC code, jurisdiction) and designated operational contacts. Banks can be in Active, Suspended, or Sanctioned status, with governance controlling state transitions.
Business Purpose: Establishes trusted participant network, enables know-your-bank verification, supports regulatory compliance through status flags.
Access Control & Permissions
Implements comprehensive role-based authorization ensuring personnel can only perform actions appropriate to their function and bank affiliation. Roles include bank operators (payment creation, settlement), compliance agents (screening), settlement executors, governance administrators, and auditors.
Business Purpose: Segregates duties, prevents unauthorized actions, enables audit accountability, supports compliance with operational risk requirements.
Risk Policy Management
Enables banks to establish bilateral credit limits per counterparty per currency. The protocol tracks real-time utilization as obligations are created and released as settlements finalize. Banks can set expiration dates, freeze counterparty relationships, or adjust limits as risk appetites evolve.
Business Purpose: Controls counterparty credit risk exposure, prevents overcommitment, enables dynamic risk management, supports treasury policy enforcement.
Settlement Rail Configuration
Defines the available mechanisms for executing final value transfer. Rails are categorized by type (on-chain token transfer, off-chain reserve movement, cross-chain bridge, liquidity provider RFQ) and associated with specific currencies. Governance can activate, deactivate, or freeze rails in response to operational or security concerns.
Business Purpose: Provides settlement optionality, enables cost optimization, supports business continuity through rail redundancy, manages operational risk.
Attestor Management
Configures the trusted third-party groups responsible for validating custody proofs. Each attestor set defines a quorum requirement (e.g., 2-of-3 signatures required), ensuring no single attestor can unilaterally approve or block payments.
Business Purpose: Distributes trust, prevents single points of failure, supports third-party validation requirements, enables independent verification.
Audit Event Logging
Provides an append-only record of all protocol actions, including payment state transitions, role grants/revocations, configuration changes, and settlement finalizations. Events include actor identity, timestamp, and relevant context.
Business Purpose: Supports regulatory examination, enables dispute resolution, provides compliance evidence, facilitates operational troubleshooting.
Layer 2: Payment Processing
This layer manages the creation, validation, and lifecycle tracking of individual cross-bank payment instructions.
Payment Instruction Management
Serves as the central state machine for all payments, tracking each instruction through a nine-state lifecycle from creation to finalization or failure. Maintains links to custody proofs, screening results, interbank obligations, and settlement tickets.
Payment States:
- CREATED: Initiated by sending bank, funds locked
- LOCK_CONFIRMED: Custody proof validated
- SCREENED: Compliance check completed
- ILO_ISSUED: Interbank obligation created
- CREDIT_RELEASED: Beneficiary provisionally credited
- NETTED: Included in netting calculation
- SETTLED: Final settlement completed
- FAILED: Screening rejected
- REVERTED: Timeout or cancellation
Business Purpose: Provides single source of truth for payment status, enables exception handling, supports customer inquiry resolution, facilitates reconciliation.
Interbank Liability Engine
Creates and manages formal debt obligations between banks. When a payment clears screening and custody validation, an ILO is issued representing the sending bank's commitment to pay the receiving bank. ILOs are currency-specific and link back to originating payments while abstracting away end-customer details.
Business Purpose: Establishes interbank settlement obligations, separates customer-facing transactions from bank-level settlement, enables netting pool creation, supports credit risk tracking.
Layer 3: Custody & Compliance
This layer ensures payments are fully backed by escrowed funds and meet regulatory screening requirements.
Escrow Management
Coordinates the locking, validation, and release of funds backing payment instructions. Assets are held in escrow vaults (on-chain for digital assets, off-chain for traditional currencies) and can only be released upon settlement finalization or payment reversal.
Escrow States:
- LOCKED: Funds escrowed, backing active payment
- RELEASED: Transferred to settlement executor
- UNLOCKED: Returned to sender (revert scenario)
Business Purpose: Ensures payment pre-funding, eliminates unsecured interbank credit, supports settlement guarantee, protects against sender default.
Custody Proof Validation
Implements a multi-step verification process ensuring escrow locks are legitimate, match payment parameters, and are attested by quorum of independent validators. Validation checks include bank identity, amount matching, currency consistency, proof freshness, and attestor signature verification.
Business Purpose: Prevents fraudulent payment creation, validates third-party custody attestation, ensures payment-escrow linkage integrity, supports audit verification.
Compliance Screening
Provides receiving banks with designated checkpoints to perform required AML/KYC checks before accepting payment responsibility. Banks record screening outcomes (approved/rejected) on-chain, with automatic timeout mechanisms preventing indefinite holds.
Screening Requirements:
- Must complete within protocol-defined deadline (typically 24 hours)
- Outcome recorded by authorized compliance agent
- Auto-revert triggered if deadline exceeded
- Full audit trail of screening decisions
Business Purpose: Enforces regulatory compliance, prevents banks from receiving sanctioned funds, supports customer due diligence requirements, enables screening audit trail.
Layer 4: Netting & Settlement
This layer optimizes capital efficiency through multilateral offset calculations and coordinates final settlement execution.
Multilateral Netting
Operates periodic windows during which banks include outstanding ILOs for offset calculation. The protocol computes net positions for each bank pair by currency, identifying the single net amount one bank owes the other. This dramatically reduces the number and value of required settlements.
Netting Example:
Without Netting:
Bank A → Bank B: $1,000,000
Bank B → Bank A: $ 750,000
Total Settlement Volume: $1,750,000
With Netting:
Net Position: Bank A → Bank B: $250,000
Settlement Reduction: 85.7%
Netting Window Lifecycle:
- OPEN: Banks include eligible ILOs
- CLOSED: No further inclusions, calculation in progress
- FINALIZED: Settlement tickets created, netting complete
Business Purpose: Reduces settlement volume, minimizes capital requirements, lowers transaction costs, improves operational efficiency, reduces settlement risk.
Settlement Coordination
Manages the creation, execution, and finalization of settlement tickets representing net amounts to be transferred between banks. Settlement executors select optimal rails, execute transfers, and submit proof of completion. Finalization validates all proofs, releases escrowed funds, and marks covered obligations as settled.
Settlement Ticket States:
- PENDING: Created, awaiting execution
- SUBMITTED: Executor has provided completion proof
- FINALIZED: Protocol has validated and released all obligations
- EXPIRED: Deadline passed without finalization
Business Purpose: Orchestrates final settlement, enables rail flexibility, ensures atomic completion, releases credit limits, finalizes customer credits.
Payment Lifecycle
Complete State Transition Diagram
┌─────────────────────────────────────┐
│ │
▼ │
┌──────────────────┐ │
START │ CREATED │ TIMEOUT│
└──────────────────┘ │
│ │
│ Lock Proof Validated │
▼ │
┌──────────────────┐ │
│ LOCK_CONFIRMED │ │
└──────────────────┘ │
│ │
│ Screening Completed │
▼ │
┌──────────────────┐ ┌──────────┐ │
│ SCREENED │────────> │ FAILED │ │
└──────────────────┘ Rejected └──────────┘ │
│ END │
│ Screening Approved │
▼ │
┌──────────────────┐ │
│ ILO_ISSUED │ │
└──────────────────┘ │
│ │
│ Beneficiary Credited │
▼ │
┌──────────────────┐ │
│ CREDIT_RELEASED │ │
└──────────────────┘ │
│ │
│ Included in Netting │
▼ │
┌──────────────────┐ │
│ NETTED │ │
└──────────────────┘ │
│ │
│ Settlement Finalized │
▼ │
┌──────────────────┐ │
│ SETTLED │ │
└──────────────────┘ │
END │
│
┌──────────┐
│ REVERTED │
└──────────┘
END
State Descriptions
CREATED Payment instruction submitted by sending bank operator. Debtor participant's funds are reserved, and escrow lock is established. Payment assigned unique identifier and screening deadline.
LOCK_CONFIRMED Independent attestors have validated that escrowed funds exist, match payment parameters, and are properly locked. Nine-step validation process completed successfully.
SCREENED Receiving bank compliance agent has completed required AML/KYC checks and recorded approval. Payment is now eligible for ILO issuance.
ILO_ISSUED Interbank liability obligation created, representing sending bank's formal commitment. Bilateral credit limit is consumed. Payment details abstracted to bank-level obligation.
CREDIT_RELEASED Receiving bank has issued provisional credit to beneficiary participant. Customer experiences instant payment receipt, though interbank settlement is deferred.
NETTED Payment included in multilateral netting calculation. Covered by settlement ticket with Merkle proof of inclusion.
SETTLED Final settlement completed and validated. Bilateral credit limit released, escrow released to executor, all obligations finalized. Payment lifecycle complete.
FAILED Payment rejected during screening due to compliance concerns. Funds remain in escrow pending revert process.
REVERTED Payment cancelled due to timeout, screening failure, or operational error. Escrow unlocked and returned to sender, all obligations nullified.
End-to-End Workflows
Workflow 1: Standard Cross-Bank Payment
Scenario: Alice (customer of Bank A) sends $1,000 USD to Bob (customer of Bank B) using the INTERLOCC Protocol.
Step 1: Payment Initiation (Bank A Operator)
Alice deposits $1,000 USD into her account at Bank A. A Bank A operator creates a payment instruction in the INTERLOCC Protocol specifying:
- Debtor participant (Alice's protocol identifier)
- Creditor participant (Bob's protocol identifier)
- Sending bank (Bank A)
- Receiving bank (Bank B)
- Amount ($1,000 USD)
- Settlement rail preference
The protocol reserves Alice's funds, preventing withdrawal or double-spending. Simultaneously, Bank A locks the equivalent value in an escrow vault.
Outcome: Payment state = CREATED, escrow = LOCKED, Alice's available balance = $0
Step 2: Custody Proof Submission (Bank A Operator + Attestors)
Bank A generates a custody proof containing:
- Escrow vault reference
- Locked amount and currency
- Payment identifier linkage
- Expiration timestamp
This proof is signed by a quorum of independent attestors (e.g., 2-of-3 custody validators) who verify off-chain that the escrow actually exists and matches the claimed parameters.
Bank A submits the multi-signed proof to the protocol. The protocol validates:
- Payment exists and is in CREATED state
- Bank A is the debtor bank
- Amount, currency, and rail match payment instruction
- Attestor signatures form valid quorum
- Proof has not expired
- On-chain escrow record exists and matches
Outcome: Payment state = LOCK_CONFIRMED, payment is now eligible for screening
Step 3: Compliance Screening (Bank B Agent)
A compliance agent at Bank B (the receiving institution) reviews the payment for regulatory requirements:
- Checks Alice's identifier against sanctions lists
- Validates transaction purpose and supporting documentation
- Performs customer due diligence per internal policies
- Confirms compliance with jurisdictional AML/KYC requirements
The agent records the screening outcome in the protocol, selecting either APPROVED or REJECTED. If approved, the payment advances. If rejected, the payment enters FAILED state and will be reverted.
Important: The protocol enforces a screening deadline (typically 24 hours). If Bank B does not screen the payment before the deadline, anyone can trigger an automatic timeout revert, ensuring payments cannot languish indefinitely.
Outcome: Payment state = SCREENED (if approved) or FAILED (if rejected)
Step 4: ILO Issuance (Bank A Operator)
With screening complete and custody validated, Bank A's operator issues an Interbank Liability Obligation. The protocol:
- Creates ILO recording that Bank A owes Bank B $1,000 USD
- Checks that Bank A has available bilateral credit limit with Bank B
- Consumes $1,000 of Bank A → Bank B credit limit
- Links ILO to original payment instruction
- Omits all participant-level details (Alice and Bob's identities do not appear in the ILO)
This ILO now represents a formal, protocol-recognized debt that will be settled through the netting and settlement process.
Outcome: Payment state = ILO_ISSUED, credit limit utilized = +$1,000, ILO status = PENDING
Step 5: Provisional Credit (Automatic)
The protocol's event monitoring system detects the ILO issuance and automatically triggers provisional credit release at Bank B:
- Bank B's internal float (liquidity pool) is reserved
- Bob's account is credited $1,000 USD
- Credit is marked as provisional, backed by the ILO
- Bob can now access and spend these funds immediately
From Bob's perspective: The payment is complete. He has received $1,000 USD and can use it for any purpose.
From Bank B's perspective: They have fronted liquidity to Bob, backed by Bank A's ILO. Final settlement is deferred until the next netting window.
Outcome: Payment state = CREDIT_RELEASED, Bob's available balance = +$1,000
Step 6: Netting Window Participation (Bank Operators)
Periodically (e.g., every 6 hours), the protocol opens a multilateral netting window. Bank operators include outstanding ILOs that are ready for settlement. In this example, assume:
- Alice's payment (Bank A → Bank B: $1,000) is included
- Several other payments are also included in the same window
The protocol groups all ILOs by bank pair and currency, then calculates net positions. For the Bank A ↔ Bank B pair in USD:
- Bank A → Bank B: $1,000 (Alice's payment)
- Bank B → Bank A: $600 (other payments in opposite direction)
- Net Position: Bank A owes Bank B $400 USD
The netting window closes, and the protocol creates settlement tickets representing these net obligations.
Outcome: Payment state = NETTED, settlement ticket created for Bank A → Bank B: $400
Efficiency: Settlement volume reduced by 60% compared to settling each payment individually.
Step 7: Settlement Execution (Settlement Executor)
A designated settlement executor (typically a specialized service provider) monitors pending settlement tickets. For the Bank A → Bank B $400 ticket, the executor:
- Selects the optimal settlement rail (e.g., on-chain USDC transfer due to cost and speed)
- Executes the $400 transfer from Bank A's settlement account to Bank B's settlement account
- Obtains proof of completion (transaction hash, confirmation receipt)
- Submits this proof to the protocol
Outcome: Settlement ticket state = SUBMITTED, awaiting finalization
Step 8: Settlement Finalization (Bank Operator or Governance)
A Bank A or Bank B operator (or governance administrator) finalizes the settlement ticket by submitting the list of covered ILO identifiers. The protocol:
- Validates that each ILO is proven to be covered by the settlement ticket (using Merkle proof)
- Confirms all ILOs in the batch are in NETTED state
- Releases the $1,000 bilateral credit limit (Bank A → Bank B)
- Releases Alice's original $1,000 escrow to the settlement executor
- Releases Bank B's $1,000 reserved float
- Marks the ILO as SETTLED
- Marks Alice's payment as SETTLED
Final State:
- Alice: Sent $1,000 (debited)
- Bob: Received $1,000 (credited, now finalized)
- Bank A → Bank B credit limit: Restored to original capacity
- Escrow: Released to executor for operational costs
- Payment lifecycle: Complete
Workflow 2: Screening Timeout & Automatic Revert
Scenario: Bank A sends a payment to Bank B, but Bank B fails to screen the payment within the 24-hour deadline.
Timeline
T+0 Hours: Payment created, escrow locked, Alice's funds reserved
T+1 to T+23 Hours: Payment sits in CREATED state awaiting screening
T+24 Hours: Screening deadline expires
T+24+ Hours: Anyone (bank operator, governance, or even a public watchdog service) calls the timeout function
Automatic Revert Process
The protocol detects that the current time exceeds the screening deadline and initiates an automatic revert:
- Escrow Unlock: The $1,000 escrow lock is released, returning funds to Bank A's control
- Reservation Release: Alice's internal account reservation is released
- Refund: Alice's available balance is restored to $1,000
- State Transition: Payment marked as REVERTED
- Audit Log: Event recorded showing timeout revert with timestamp and caller
Result
Alice receives her funds back. No interbank liability was created. No credit limit was consumed. The payment failed safely without requiring manual intervention.
Business Value: Prevents payments from blocking capital indefinitely, ensures operational SLAs are enforced, protects customer funds.
Workflow 3: Complex Multilateral Netting
Scenario: Four banks have multiple cross-payments, demonstrating the power of multilateral netting.
Outstanding Payments
| From | To | Amount |
|---|---|---|
| Bank A | Bank B | $1,000 |
| Bank A | Bank C | $500 |
| Bank B | Bank A | $700 |
| Bank B | Bank C | $300 |
| Bank C | Bank A | $200 |
| Bank C | Bank B | $400 |
Total Gross Settlement Requirement: $3,100
Netting Calculation
The protocol calculates net positions for each bank pair:
Bank A ↔ Bank B (USD):
- A → B: $1,000
- B → A: $700
- Net: Bank A owes Bank B $300
Bank A ↔ Bank C (USD):
- A → C: $500
- C → A: $200
- Net: Bank A owes Bank C $300
Bank B ↔ Bank C (USD):
- B → C: $300
- C → B: $400
- Net: Bank C owes Bank B $100
Settlement Tickets Created
- Ticket #1: Bank A → Bank B: $300
- Ticket #2: Bank A → Bank C: $300
- Ticket #3: Bank C → Bank B: $100
Total Net Settlement Requirement: $700
Capital Efficiency: 77.4% reduction in settlement volume
Settlement Process
Each settlement ticket is executed independently by executors using the most cost-effective rail for each bank pair. All six original payments are marked SETTLED when their respective tickets are finalized, despite only three actual value transfers occurring.
Customer Experience: All six beneficiaries received provisional credit immediately when ILOs were issued. They experienced instant payments, while banks optimized settlement costs and capital usage.
Actor Roles & Capabilities
Role-Permission Matrix
| Role | Assigned To | Key Capabilities | Scope |
|---|---|---|---|
| Governance | Protocol governors, board members | • Register/suspend banks • Configure settlement rails • Set bilateral credit limits • Open/close netting windows • Emergency pause • Manage attestor sets | Protocol-wide |
| Bank Operator | Bank treasury staff, operations managers | • Create payment instructions • Submit custody proofs • Issue ILOs • Include ILOs in netting • Finalize settlement tickets • Configure bank modules | Bank-specific |
| Bank Agent | Compliance officers, customer service | • Screen payments (approve/reject) • Manage participant deposits/withdrawals • View participant balances • Record screening outcomes | Bank-specific |
| Settlement Executor | Third-party settlement providers | • Execute settlement tickets • Select settlement rails • Submit completion proofs • Claim escrowed funds | Protocol-wide |
| Attestor | Independent custody validators | • Sign custody proofs • Verify escrow existence • Participate in quorum validation | Attestor-set specific |
| Auditor | Regulators, internal audit, external auditors | • Query audit event log • Export compliance reports • View all transactions (read-only) • Monitor system metrics | Protocol-wide (read-only) |
| Emergency Admin | Security response team | • Trigger emergency pause • Freeze specific rails • Suspend banks (temporary) | Protocol-wide |
Bank-Scoped Authorization
Important: Bank Operators and Bank Agents are explicitly assigned to specific banks. A Bank A operator cannot create payments for Bank B, and a Bank B compliance agent cannot screen Bank A's payments. This segregation is enforced at the protocol level, not through voluntary adherence.
When a bank is registered, the protocol tracks:
- Authorized operators (personnel who can perform operational actions)
- Authorized agents (personnel who can perform compliance and customer service actions)
- Module addresses (technical infrastructure components specific to that bank)
Operational Workflows by Role
Bank Operator Daily Activities
Morning:
- Review pending payments awaiting custody proof submission
- Submit custody proofs for overnight payment batches
- Monitor bilateral credit limit utilization across counterparties
Midday:
- Issue ILOs for payments that have cleared screening
- Review failed/reverted payments for resolution
- Coordinate with compliance on any screening delays
Afternoon (if netting window is open):
- Include eligible ILOs in the current netting window
- Review net positions to anticipate settlement requirements
Evening (post-settlement execution):
- Finalize settlement tickets
- Verify escrow releases and credit limit restorations
- Reconcile internal ledgers with protocol state
Bank Agent Daily Activities
Continuous:
- Monitor incoming payments requiring screening
- Perform AML/KYC checks on debtor participants
- Record screening outcomes (approve/reject) in protocol
As Needed:
- Process participant deposit requests
- Process participant withdrawal requests
- Respond to customer inquiries about payment status
- Investigate payments flagged by automated screening tools
End of Day:
- Ensure all payments within deadline have been screened
- Review any auto-reverted payments for customer communication
- Document compliance decisions for audit trail
Settlement Executor Activities
Continuous Monitoring:
- Watch for new settlement tickets entering PENDING state
- Evaluate optimal rail selection based on cost, speed, and liquidity
Execution Process:
- Select settlement rail (SWIFT, on-chain USDC, bridge, RFQ)
- Execute value transfer via selected rail
- Obtain proof of completion
- Submit proof to protocol
- Monitor for finalization
- Claim released escrow funds
Performance Metrics:
- Execution speed (time from ticket creation to proof submission)
- Cost efficiency (fees per settlement)
- Success rate (finalized vs expired tickets)
Governance Activities
Strategic:
- Onboard new participating banks (due diligence, registration)
- Configure new settlement rails as markets evolve
- Set protocol-wide risk parameters
Operational:
- Open/close netting windows according to schedule
- Review and approve credit limit adjustment requests
- Monitor system health and performance metrics
Emergency Response:
- Investigate security incidents
- Execute emergency pause if critical vulnerability discovered
- Coordinate with banks on incident resolution
- Resume operations after issue mitigation
On-Chain Transparency
What Gets Recorded
The INTERLOCC Protocol records all operationally significant events on the blockchain, creating an immutable, auditable record of all activities. This transparency enables compliance, dispute resolution, and operational oversight without compromising participant privacy.
Payment Records
Each payment instruction is recorded with:
- Unique payment identifier
- Debtor participant (pseudonymous protocol address)
- Creditor participant (pseudonymous protocol address)
- Debtor bank (institution-level identifier)
- Creditor bank (institution-level identifier)
- Amount and currency
- Current state (CREATED, SCREENED, SETTLED, etc.)
- State transition history with timestamps
- Links to custody proof, ILO, and settlement ticket
- Screening outcome (if completed)
- Revert reason (if applicable)
Privacy Note: Participant identifiers are blockchain addresses (e.g., 0x1234...5678), not real-world identities. Banks maintain off-chain mappings of these addresses to actual customer accounts, ensuring compliance while preserving on-chain privacy.
Interbank Liability Obligations (ILOs)
ILOs represent formal bank-to-bank debts and are recorded with:
- Unique ILO identifier
- Debtor bank
- Creditor bank
- Amount and currency
- Issuance timestamp
- Link to originating payment
- Current status (PENDING, NETTED, SETTLED, DEFAULTED)
- Netting window identifier (if netted)
- Settlement ticket identifier (if settled)
Abstraction: ILOs contain only bank-level information. Customer details from the originating payment are intentionally omitted, providing privacy at the settlement layer.
Netting Windows
Each netting cycle is recorded with:
- Unique window identifier
- Currency
- Open timestamp
- Close timestamp
- List of included ILO identifiers
- Calculated net positions (bank pair, signed amount)
- Settlement ticket identifiers created from this window
- Status (OPEN, CLOSED, FINALIZED)
Transparency: Any observer can verify that net position calculations are correct by reviewing the included ILOs and applying the netting algorithm.
Settlement Tickets
Settlement tickets representing final value transfers are recorded with:
- Unique ticket identifier
- Debtor bank
- Creditor bank
- Net amount and currency
- Netting window source
- Merkle root of covered ILO identifiers
- Execution proof (transaction hash or receipt)
- Status (PENDING, SUBMITTED, FINALIZED, EXPIRED)
- Executor identifier
- Finalization timestamp
Atomic Guarantee: Settlement tickets must be finalized with complete Merkle proofs for all covered ILOs, ensuring all-or-nothing settlement.
Audit Events
A comprehensive event log records:
- Payment state transitions (CREATED → SCREENED, etc.)
- ILO lifecycle events (ISSUED, NETTED, SETTLED)
- Netting window operations (OPENED, CLOSED, FINALIZED)
- Settlement ticket operations (CREATED, EXECUTED, FINALIZED)
- Configuration changes (rail activated, limit set, bank registered)
- Authorization actions (role granted, operator assigned)
- Emergency actions (pause triggered, rail frozen)
Each event includes:
- Event type
- Actor (who performed the action)
- Timestamp
- Relevant identifiers (payment ID, ILO ID, etc.)
- Event-specific data
What Is NOT Recorded
To protect commercial confidentiality and participant privacy:
Customer Identities: Real names, account numbers, and personal information are never recorded on-chain. Only pseudonymous protocol addresses appear.
Transaction Purposes: Payment descriptions, invoice references, or business context are handled off-chain.
Commercial Terms: Bilateral agreements between banks (e.g., negotiated credit limit terms, fee arrangements) are not public.
Rail-Specific Details: Exact SWIFT message content, on-chain transaction routing, or liquidity provider quotes are not recorded in the protocol.
Bank Internal Operations: How banks manage customer accounts, screen transactions, or operate their treasury functions remains private.
Traceability Example
Consider a payment from Alice (Bank A) to Bob (Bank B). The on-chain record would show:
Payment #87623:
Debtor Participant: 0x1a2b3c4d... (Alice's protocol address)
Creditor Participant: 0x9e8f7d6c... (Bob's protocol address)
Debtor Bank: 0xBankA...
Creditor Bank: 0xBankB...
Amount: 1000.00 USD
State History:
- CREATED at 2026-01-15 09:00:00 UTC by 0xOperatorA...
- LOCK_CONFIRMED at 2026-01-15 09:05:00 UTC (proof #1234)
- SCREENED at 2026-01-15 10:30:00 UTC by 0xAgentB... (APPROVED)
- ILO_ISSUED at 2026-01-15 10:35:00 UTC (ILO #5678)
- CREDIT_RELEASED at 2026-01-15 10:35:30 UTC (automatic)
- NETTED at 2026-01-15 15:00:00 UTC (window #42)
- SETTLED at 2026-01-15 18:00:00 UTC (ticket #999)
Linked Resources:
- Custody Proof: #1234 (attestors: 0xAtt1..., 0xAtt2..., 0xAtt3...)
- ILO: #5678 (BankA → BankB, 1000 USD)
- Netting Window: #42 (15 ILOs included)
- Settlement Ticket: #999 (BankA → BankB, 400 USD net)
Auditability: A regulator or auditor can trace the complete lifecycle from creation to settlement, verify that screening occurred, confirm that settlement happened, and validate that all protocol rules were followed.
Privacy: The regulator cannot determine from the on-chain record alone that Alice Smith (account #12345 at Bank A) sent money to Bob Jones (account #67890 at Bank B). That mapping requires access to Bank A and Bank B's internal systems.
Security & Governance Model
Layered Security Architecture
The INTERLOCC Protocol implements defense-in-depth security across multiple layers:
Layer 1: Access Control
Role-Based Authorization: Every protocol function is restricted to specific roles. Bank operators cannot perform governance actions, compliance agents cannot issue ILOs, and settlement executors cannot screen payments.
Bank-Scoped Permissions: Bank operators and agents are explicitly assigned to specific banks. Cross-bank operations are prevented at the protocol level.
Least Privilege Principle: Roles are granted the minimum permissions necessary for their function. For example, auditors have read-only access, preventing accidental or malicious data modification.
Layer 2: Validation & Verification
Payment Instruction Validation:
- No self-payments (sending and receiving banks must differ)
- Positive, non-zero amounts
- Valid currency codes
- Active, unfrozen settlement rails
- Unique payment identifiers (no duplicates)
ILO Issuance Validation:
- Payment must be in LOCK_CONFIRMED state
- Valid custody proof with attestor quorum
- Sufficient bilateral credit limit available
- Bank pair not frozen or suspended
- Credit limit not expired
Settlement Finalization Validation:
- Merkle proof verification for all covered ILOs
- Atomicity guarantee (all ILOs in batch or none)
- Ticket in valid state (PENDING or SUBMITTED)
- Sum of ILO amounts equals ticket amount
- All payments in appropriate states
Layer 3: Cryptographic Guarantees
Custody Proofs: Multi-signature attestation ensures escrow existence is verified by independent third parties, not just the sending bank.
Merkle Proofs: Settlement tickets cryptographically commit to specific ILOs, preventing partial settlement or unauthorized substitution.
Event Signatures: All audit events are cryptographically signed, ensuring non-repudiation and tamper evidence.
Layer 4: Bilateral Credit Limits
Purpose: Prevent excessive counterparty exposure by enforcing maximum unsettled obligations between any two banks.
Operation:
- Governance or bank operators set limits per bank pair per currency
- Limits are consumed when ILOs are issued
- Limits are released when settlements are finalized
- Real-time utilization prevents over-commitment
Example:
Bank A → Bank B USD Limit: $5,000,000
Current Utilization: $3,200,000
Available: $1,800,000
New ILO Request: $2,000,000
Result: REJECTED (exceeds available limit)
After settlement of $1,500,000 in ILOs:
Updated Utilization: $1,700,000
Available: $3,300,000
Risk Mitigation: Even if a bank were to default, counterparty exposure is capped at the pre-agreed limit.
Safeguards & Circuit Breakers
Screening Deadlines
Problem: A payment could remain in screening indefinitely, locking capital and preventing customer refunds.
Solution: Every payment has a screening deadline (default 24 hours). If screening is not completed by this time, anyone can trigger an automatic revert that:
- Unlocks escrow
- Refunds debtor participant
- Marks payment as REVERTED
- Logs timeout event
Benefit: Ensures operational SLAs, prevents capital lockup, protects customer funds.
Bank Pair Freezing
Problem: A bank may need to temporarily halt transactions with a specific counterparty due to credit concerns, operational issues, or compliance alerts.
Solution: Governance or bank operators can freeze a bank pair, preventing new ILO issuance between those institutions. Existing ILOs can still settle normally.
Use Cases:
- Temporary credit limit suspension
- Bilateral dispute resolution
- Regulatory compliance holds
- Operational incident response
Settlement Ticket Expiration
Problem: Settlement tickets could remain pending indefinitely if executors fail to act.
Solution: Each ticket has a deadline. After expiration, the ticket enters EXPIRED state. While automatic fund recovery is not implemented in the current version, expired tickets are flagged for governance review and manual intervention.
Future Enhancement: Automatic revert of netted ILOs back to PENDING state, allowing re-inclusion in subsequent netting windows.
Emergency Pause
Problem: A critical security vulnerability or operational incident may require immediate system shutdown.
Solution: Governance or emergency administrators can trigger a protocol-wide pause that:
- Blocks all state-changing operations (payment creation, ILO issuance, netting, settlement)
- Allows read-only queries to continue (audit access, balance checks)
- Prevents fund withdrawals or transfers
- Requires explicit unpause action to resume
Use Cases:
- Zero-day vulnerability discovery
- Smart contract upgrade coordination
- Regulatory intervention response
- Coordinated testing or maintenance
Rail Freezing
Problem: A specific settlement rail may become unreliable, compromised, or illiquid.
Solution: Governance can freeze individual rails, preventing new payments from using that rail. Existing payments can be settled via alternative rails or manual intervention.
Example: If a cross-chain bridge is hacked, governance immediately freezes the BRIDGE rail, preventing new exposure while existing settlements complete via SWIFT or on-chain transfers.
Failure Handling
Screening Rejection
Trigger: Bank agent marks payment as REJECTED during screening
Process:
- Payment enters FAILED state
- Revert coordinator is invoked
- Escrow unlocked and returned to sending bank
- Debtor participant refunded
- No ILO created, no credit limit consumed
- Audit event logged with rejection reason
Customer Impact: Sender receives funds back, recipient never sees payment
ILO Default Declaration
Trigger: Governance declares that a bank has defaulted on obligations
Process:
- Specific ILOs marked as DEFAULTED
- Affected bank pair frozen (no new ILOs)
- Affected payments marked as FAILED
- Credit limits frozen
- Audit events logged
- Manual resolution process initiated (out-of-protocol)
Rare Event: This represents a bank-level failure and would trigger broader industry response mechanisms.
Settlement Executor Failure
Trigger: Settlement executor fails to execute a ticket within the deadline
Process:
- Ticket enters EXPIRED state
- Governance reviews situation
- Manual intervention options:
- Assign new executor
- Extend deadline
- Revert netted ILOs for re-inclusion
Mitigation: Multiple executor services provide redundancy. If primary executor fails, governance can quickly reassign.
Audit & Compliance
Comprehensive Event Logging
100% Coverage: Every state transition, configuration change, and authorization action generates an immutable audit event.
Structured Data: Events follow consistent schemas, enabling automated compliance reporting and anomaly detection.
Indexed Access: Events can be filtered by type, actor, resource, or time range, supporting targeted investigations.
Role Accountability
Actor Attribution: Every action records the identity of the person or system that performed it, enabling accountability audits.
Segregation of Duties: No single role can complete a payment end-to-end. Operators create, agents screen, executors settle—requiring cooperation and preventing unilateral fraud.
Regulatory Reporting
Export Capabilities: Auditors can extract all events for a given bank, time period, or payment lifecycle stage.
Compliance Queries: Pre-built queries for common regulatory requirements:
- All payments screened in last 30 days
- All ILOs involving specific bank
- All settlement tickets above $1M threshold
- All failed/reverted payments with reasons
Dispute Resolution
Complete Traceability: Any payment can be traced from creation through settlement, showing:
- Who created it and when
- When custody was proven and by whom
- When screening occurred and the outcome
- When ILO was issued
- When beneficiary was credited
- Which netting window included it
- Which settlement ticket covered it
- When final settlement occurred
This complete record enables rapid dispute resolution without relying on potentially inconsistent internal bank records.
Operational Visibility
Dashboard Capabilities
The INTERLOCC Protocol provides comprehensive monitoring and reporting capabilities suitable for bank operators, compliance teams, treasury management, and executive oversight.
Payment Monitoring Dashboard
Real-Time Metrics:
- Total payments created today
- Payments by state (pending, screened, settled, failed)
- Average time to settlement
- Failed payment rate
- Auto-revert count (screening timeouts)
Payment Search & Filter:
- By payment ID
- By debtor/creditor bank
- By state
- By currency
- By date range
- By amount threshold
Drill-Down Details:
- Complete state transition history
- Linked custody proof, ILO, settlement ticket
- Screening outcome and timestamp
- Settlement rail used
- Executor identity
ILO Management Dashboard
Real-Time Metrics:
- Total outstanding ILOs
- Outstanding ILO value by currency
- ILOs by status (pending, netted, settled)
- Average ILO age
- Default count (should be zero in normal operations)
Bank Pair Analysis:
- Outstanding ILOs per counterparty
- Bilateral exposure by bank pair
- Trend analysis (increasing/decreasing exposure)
Lifecycle Tracking:
- ILOs awaiting netting inclusion
- ILOs in current netting window
- ILOs settled today
- Historical settlement patterns
Credit Limit Dashboard
Utilization Metrics:
- Current utilization % by bank pair
- Available credit by counterparty
- Limits approaching capacity (>80% utilized)
- Limits expiring soon (within 7 days)
Risk Indicators:
- Bank pairs frozen (with reasons)
- Credit limit breaches prevented
- Historical utilization peaks
- Seasonal usage patterns
Configuration Management:
- All bilateral limits with expiry dates
- Recent limit changes
- Pending limit adjustment requests
Netting Operations Dashboard
Current Window Status:
- Open windows with close times
- ILOs included so far
- Projected net positions (preview)
- Participation rate (banks including ILOs)
Historical Analysis:
- Netting efficiency % per window
- Volume reduction trends
- Average window size (ILO count)
- Settlement ticket count per window
Net Position Visualization:
- Bank pair net positions (signed amounts)
- Network graph showing who owes whom
- Largest net positions
- Currency distribution
Settlement Tracking Dashboard
Pipeline Status:
- Tickets pending execution
- Tickets awaiting finalization
- Tickets finalized today
- Expired tickets (requires intervention)
Executor Performance:
- Execution time (average, p50, p99)
- Success rate by executor
- Rail selection patterns
- Fee efficiency
Settlement Coverage:
- ILOs covered by each ticket
- Merkle proof validation status
- Escrow release amounts
- Credit limit releases
Compliance & Audit Dashboard
Screening Metrics:
- Payments screened today
- Average screening time
- Screening approval rate
- Payments approaching deadline
- Auto-reverts due to timeout
Audit Event Explorer:
- All events by type
- Events by actor
- Events by resource (payment, ILO, ticket)
- Time-based filtering
- Export to CSV/JSON
Regulatory Reports:
- Large payment report (>$10K threshold)
- Failed payment report with reasons
- Cross-border payment summary
- Bank activity summary
Alert & Notification System
Operational Alerts
For Bank Operators:
- New payment awaiting custody proof submission
- ILO issuance eligible (screened and locked)
- Netting window opened (include ILOs)
- Settlement ticket ready for finalization
- Payment approaching screening deadline
For Compliance Agents:
- New payment requires screening
- Screening deadline in 4 hours
- High-value payment flagged (>$100K)
- Counterparty on watchlist
For Treasury/Risk:
- Credit limit utilization >80%
- Credit limit approaching expiry
- Bank pair frozen (new development)
- Large settlement ticket created (>$1M)
System Health Alerts
For Governance:
- Emergency pause triggered
- Settlement rail frozen
- Bank suspended
- High rate of payment failures
- Settlement ticket expiration detected
For Technical Operations:
- Attestor quorum failure
- Executor missed deadline
- Unusually high gas costs
- RPC endpoint connectivity issues
Reporting Capabilities
Daily Operational Report
- Payments created, screened, settled, failed
- ILOs issued and settled
- Netting windows opened/closed
- Settlement tickets finalized
- Credit limit changes
- Outstanding obligations by bank
Delivery: Automated email, dashboard, API
Monthly Compliance Report
- Total payment volume by currency
- Cross-border payment count
- Screening approval/rejection rates
- Auto-revert count and reasons
- Large payment summary (>$10K)
- Failed payment analysis
Delivery: PDF export, regulatory submission format
Quarterly Risk Report
- Peak bilateral exposure by bank pair
- Average credit limit utilization
- Settlement efficiency (netting %)
- Average time to settlement
- Default incidents (should be zero)
- Bank pair freeze incidents
Delivery: Executive summary, detailed appendix
Ad-Hoc Query Interface
Custom Queries:
- All payments between two banks in date range
- All ILOs settled via specific rail
- All payments screened by specific agent
- All settlement tickets executed by specific executor
- All events involving specific payment ID
Export Formats: CSV, JSON, PDF report
Glossary
Attestor Independent third party that validates custody proofs by verifying that escrowed funds actually exist and match payment parameters. Attestors form quorums (e.g., 2-of-3) to distribute trust.
Bilateral Credit Limit Maximum unsettled obligation amount one bank is willing to carry with a specific counterparty for a given currency. Enforced in real-time as ILOs are issued and released as settlements finalize.
Custody Proof Cryptographic proof that funds backing a payment are escrowed and validated by an attestor quorum. Required before ILO issuance.
Escrow Locked funds backing a payment instruction. Held in vaults (on-chain for digital assets, off-chain for traditional currencies) until settlement finalization or payment revert.
Interbank Liability Obligation (ILO) Formal debt from one bank to another, representing the settlement obligation for one or more payments. ILOs abstract away participant details, containing only bank-level information.
Merkle Proof Cryptographic proof that a specific ILO is included in a settlement ticket's coverage set. Ensures atomic settlement (all ILOs proven or finalization fails).
Multilateral Netting Process of calculating net positions across multiple bank pairs by offsetting bilateral flows. Dramatically reduces settlement volume and capital requirements.
Netting Window Periodic cycle (e.g., every 6 hours) during which banks include outstanding ILOs for netting calculation. Windows have OPEN, CLOSED, and FINALIZED states.
Net Position Calculated amount one bank owes another after offsetting bilateral flows. For example, if Bank A → Bank B is $1,000 and Bank B → Bank A is $700, the net position is Bank A owes Bank B $300.
Payment Instruction Record of a cross-bank payment including debtor/creditor participants, banks, amount, currency, and lifecycle state. The core unit tracked through the protocol.
Provisional Credit Immediate credit issued to a beneficiary upon ILO creation, backed by the interbank obligation but prior to final settlement. Allows instant customer access while banks defer settlement.
Screening Compliance process where receiving bank performs AML/KYC checks on a payment before accepting the obligation. Results in APPROVED or REJECTED outcome.
Settlement Executor Service provider responsible for executing final value transfers between banks via selected rails (SWIFT, on-chain, bridges, RFQ). Submits proof of completion to protocol.
Settlement Rail Mechanism for executing final value transfer. Types include on-chain ERC20 transfers, off-chain reserve/SWIFT movements, cross-chain bridges, and RFQ liquidity provision.
Settlement Ticket Record of a net amount to be transferred from one bank to another, covering specific ILOs proven via Merkle root. Tickets are executed by settlement executors and finalized by bank operators.
State Transition Movement of a payment through its lifecycle (CREATED → SCREENED → SETTLED, etc.). All transitions are logged for audit and monitoring.
Conclusion
The INTERLOCC Protocol represents a fundamental reimagining of interbank settlement infrastructure, combining:
- Traditional Banking Principles: Bilateral credit limits, compliance screening, regulatory audit trails
- Modern Technology: Blockchain transparency, cryptographic proofs, real-time monitoring
- Operational Efficiency: Multilateral netting, multi-rail settlement, automated workflows
- Risk Management: Real-time exposure tracking, safeguards and circuit breakers, role-based access control
For participating financial institutions, INTERLOCC delivers:
- Capital Efficiency: 60-90% reduction in settlement volume through netting
- Customer Experience: Instant beneficiary credit versus traditional T+1/T+2 delays
- Cost Reduction: Optimized settlement rail selection, batch processing economies
- Risk Control: Real-time bilateral exposure monitoring with automatic enforcement
- Operational Transparency: Complete audit trail, comprehensive monitoring dashboards
- Regulatory Compliance: Built-in screening checkpoints, immutable event logging
The protocol is production-ready, deployed on Ethereum-compatible networks, and designed for institutional adoption. Its architecture supports gradual onboarding, multi-currency operations, and integration with existing banking infrastructure.
For more information about participating in the INTERLOCC network or technical integration details, please contact the protocol governance team.
Document Version: 1.2 Last Updated: January 2026 Classification: Client Distribution © 2026 INTERLOCC Protocol. All rights reserved.
Ready to Learn More?
This executive overview provides a comprehensive understanding of the INTERLOCC Protocol's business model and operational capabilities. For technical integration details or to participate in the network, please contact the protocol governance team.