Loading...
Loading...
DOCUMENTATION
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.
Version 1.3 Document Date: April 2026 Classification: Client Distribution
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.
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.
Traditional interbank payment systems face several fundamental challenges:
INTERLOCC introduces a four-phase operating model that transforms how banks coordinate cross-border and domestic payments:
The sending bank submits a payment instruction naming both banks, participant accounts, amount, currency, and a preferred rail. The receiving bank's compliance agent performs AML/KYC screening and records an explicit approval within the screening deadline; timeout triggers an automatic revert.
The sending bank locks the full payment amount in escrow using the token configured on the payment's rail. Independent attestors validate that the lock matches the payment (amount, rail, token, expiry) through a nine-step proof — only after this proof does the payment become eligible for liability issuance.
The sending bank issues an Interbank Liability Obligation (ILO), which consumes bilateral credit limit against the receiving bank. The receiving bank then releases provisional credit to the beneficiary, completing the customer-facing experience. Interbank settlement remains deferred.
Banks pool outstanding ILOs into multilateral netting windows. The protocol closes each window, computes bilateral net positions, and generates settlement tickets with Merkle coverage proofs. At execution time, parties agree on the final settlement rail:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Bank A │ │ INTERLOCC │ │ Bank B │
│ (debtor) │ │ Protocol │ │ (creditor) │
└─────────────┘ └─────────────┘ └─────────────┘
│ │ │
│ 1. Create payment │ │
│──────────────────────>│ │
│ │ │
│ │ 2. Screen payment │
│ │<──────────────────────│
│ │ │
│ 3. Lock escrow │ │
│──────────────────────>│ │
│ │ │
│ 4. Submit escrow │ │
│ proof (attestor │ │
│ quorum validates) │ │
│──────────────────────>│ │
│ │ │
│ 5. Issue ILO │ 6. Release credit │
│──────────────────────>│<──────────────────────│
│ │ │
│ [Netting Window] │ │
│ │ │
│ 7. Include ILOs │ 7. Include ILOs │
│──────────────────────>│<──────────────────────│
│ │ │
│ 8. Close & compute │ │
│ net positions │ │
│──────────────────────>│ │
│ │ │
│ 9. Create tickets │ │
│──────────────────────>│ │
│ │ │
│ 10. Execute — parties agree on final rail │
│ │ │
│ ── ON-CHAIN (ERC20 token matches escrow) ── │
│ Atomically: finalize ticket, release │
│ credit limit, transfer escrow to Bank B │
│ │──────────────────────>│
│ │ (escrow → creditor) │
│ │ │
│ ── OFF-CHAIN (SWIFT, reserve, bridge) ── │
│ Finalize ticket + release credit limit │
│ Escrow stays LOCKED │
│ │ │
│ │ 11. Attest (quorum) │
│ │<══════════════════════│
│ │ │
│ │ Escrow → Bank B │
│ │──────────────────────>│
│ │ │
│ Payments SETTLED, credit limit restored │
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.
The INTERLOCC Protocol is organized into four functional layers, each providing essential business capabilities:
This layer provides the governance, access control, and configuration infrastructure that underpins the entire system.
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.
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.
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.
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.
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.
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.
This layer manages the creation, validation, and lifecycle tracking of individual cross-bank payment instructions.
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 (enum order matches PaymentInstructionHub):
Business Purpose: Provides single source of truth for payment status, enables exception handling, supports customer inquiry resolution, facilitates reconciliation.
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.
This layer ensures payments are fully backed by escrowed funds and meet regulatory screening requirements.
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:
Business Purpose: Ensures payment pre-funding, eliminates unsecured interbank credit, supports settlement guarantee, protects against sender default.
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.
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:
Business Purpose: Enforces regulatory compliance, prevents banks from receiving sanctioned funds, supports customer due diligence requirements, enables screening audit trail.
This layer optimizes capital efficiency through multilateral offset calculations and coordinates final settlement execution.
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:
Business Purpose: Reduces settlement volume, minimizes capital requirements, lowers transaction costs, improves operational efficiency, reduces settlement risk.
Manages the creation, execution, and finalization of settlement tickets representing net amounts owed between bank pairs. At execution time, parties agree on the final settlement rail, which determines how the escrow is released:
Settlement Ticket States:
Business Purpose: Orchestrates final settlement, supports both atomic on-chain and attestation-gated off-chain paths, releases bilateral credit limits, delivers escrow to the creditor bank, and finalizes customer credits.
┌──────────────────┐
START │ CREATED │
└──────────────────┘
│
│ Screening Completed
▼
┌──────────────────┐ ┌──────────┐
│ SCREENED │────────> │ FAILED │
└──────────────────┘ Rejected └──────────┘
│ END
│ Escrow Locked & Proof Validated
▼
┌──────────────────┐
│ LOCK_CONFIRMED │────────┐
└──────────────────┘ │
│ │
│ ILO Issued │ Revert
▼ │ (escrow
┌──────────────────┐ │ returned
│ ILO_ISSUED │────────┤ to debtor
└──────────────────┘ │ bank)
│ │
│ Credit Released │
▼ │
┌──────────────────┐ │
│ CREDIT_RELEASED │ │
└──────────────────┘ │
│ │
│ Included in Netting Window
▼ │
┌──────────────────┐ │
│ NETTED │ │
└──────────────────┘ │
│ │
│ Ticket Finalized + Escrow
│ Released (atomic on-chain
│ OR off-chain attestation)
▼ ▼
┌──────────────────┐ ┌──────────┐
│ SETTLED │ │ REVERTED │
└──────────────────┘ └──────────┘
END END
CREATED Payment instruction submitted by the sending bank. Identifier, screening deadline, and rail preference are recorded.
SCREENED Receiving bank compliance agent has completed AML/KYC checks and recorded approval.
LOCK_CONFIRMED Debtor bank has locked the escrow and submitted a validated proof (nine-step validation including attestor quorum) linking the lock to this payment.
ILO_ISSUED Interbank Liability Obligation created, representing the sending bank's formal commitment. Bilateral credit limit is consumed. ILOs abstract away participant-level details.
CREDIT_RELEASED Receiving bank has issued provisional credit to the beneficiary. Customer experiences instant payment receipt, though interbank settlement is deferred.
NETTED Payment included in a netting window's bilateral position calculation. Eligible for ticket coverage.
SETTLED Final state reached either atomically at Execute Settlement (on-chain rail match) or at Attest Settlement (off-chain rails). Bilateral credit released, escrow released to the creditor bank, all obligations closed.
FAILED Payment rejected during screening. Escrow (if locked) can be unlocked to return funds to the debtor bank.
REVERTED Payment cancelled due to timeout, screening failure, or an operator-triggered revert. Escrow returned to the debtor bank. Only reachable from CREATED, SCREENED, LOCK_CONFIRMED, or ILO_ISSUED — not from later states.
Scenario: Alice (customer of Bank A) sends $1,000 USD to Bob (customer of Bank B). The following steps correspond directly to the pages in the Workflows sidebar.
A Bank A operator creates a payment instruction specifying:
The amount is entered in human-readable form and converted to 18-decimal wei on submission.
Outcome: Payment state = CREATED.
A compliance agent at Bank B reviews the payment — sanctions lists, transaction purpose, customer due diligence, jurisdictional AML/KYC — and records the screening outcome as APPROVED or REJECTED.
The protocol enforces a screening deadline; if it expires, anyone can trigger an automatic timeout revert.
Outcome: Payment state = SCREENED (approved) or FAILED (rejected).
The Bank A operator locks the $1,000 in TokenEscrowVault using the settlement token configured on the payment's rail. ERC20 approval for the Diamond is handled by the Token Preparation card if not already granted.
Outcome: Escrow state = LOCKED.
A proof is submitted linking the on-chain lock to the payment. EscrowProofHub runs a nine-step validation (instruction exists, debtor matches, amount matches, rail matches, token+currency match, proof not expired, attestor quorum active, on-chain lock matches) before advancing the payment.
Outcome: Payment state = LOCK_CONFIRMED.
An Interbank Liability Obligation is issued from Bank A to Bank B:
Outcome: Payment state = ILO_ISSUED, ILO status = PENDING.
Bank B marks the provisional credit to Bob as released — at this point, Bob can access the funds. Internal float at Bank B backs this release until the interbank settlement finalizes.
Outcome: Payment state = CREDIT_RELEASED.
Governance opens a multilateral netting window for a given currency with a close-time. Existing ILOs across banks will be pooled into this window.
Outcome: Window = OPEN.
Eligible ILOs (payments in ILO_ISSUED or CREDIT_RELEASED state) are added to the window. Alice's payment is one of several:
The protocol updates bilateral net positions for each (bank pair, currency) on inclusion.
Outcome: Payment state = NETTED; running net for Bank A ↔ Bank B in USD = $400 owed by Bank A.
Governance closes the window, then finalizes it. This locks in the net positions, generates settlement ticket IDs, and registers Merkle roots covering the included payments in TicketCoverageVerifier.
Outcome: Window = COMPLETED.
One ticket is created per non-zero net position. For the Bank A ↔ Bank B USD pair, a single ticket is created: Bank A → Bank B, $400.
Outcome: Ticket status = PENDING.
Efficiency: Settlement volume reduced by 60% compared to settling each payment individually.
The executor selects the final agreed rail for the ticket. The protocol branches:
If on-chain ERC20 and rail token matches the escrow token The transaction atomically:
The entire settlement completes in one transaction; no further step is required.
If off-chain rail (SWIFT, reserve, bridge, RFQ) or token mismatch The transaction only:
The escrow stays LOCKED pending attestation (Step 12).
Once the off-chain transfer is complete, the executor submits a proof signed by an active attestor quorum set. The protocol:
AttestorSetRegistryFor on-chain atomic settlements this step is skipped — the escrow was already released in Step 11.
Final State:
Scenario: Bank A sends a payment to Bank B, but Bank B fails to screen the payment within the 24-hour deadline.
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
The protocol detects that the current time exceeds the screening deadline and initiates an automatic revert:
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.
Scenario: Four banks have multiple cross-payments, demonstrating the power of multilateral netting.
| 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
The protocol calculates net positions for each bank pair:
Bank A ↔ Bank B (USD):
Bank A ↔ Bank C (USD):
Bank B ↔ Bank C (USD):
Total Net Settlement Requirement: $700
Capital Efficiency: 77.4% reduction in settlement volume
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.
| 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 |
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:
Morning:
Midday:
Afternoon (if netting window is open):
Evening (post-settlement execution):
Continuous:
As Needed:
End of Day:
Continuous Monitoring:
Execution Process:
Performance Metrics:
Strategic:
Operational:
Emergency Response:
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.
Each payment instruction is recorded with:
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.
ILOs represent formal bank-to-bank debts and are recorded with:
Abstraction: ILOs contain only bank-level information. Customer details from the originating payment are intentionally omitted, providing privacy at the settlement layer.
Each netting cycle is recorded with:
Transparency: Any observer can verify that net position calculations are correct by reviewing the included ILOs and applying the netting algorithm.
Settlement tickets representing final value transfers are recorded with:
Atomic Guarantee: Settlement tickets must be finalized with complete Merkle proofs for all covered ILOs, ensuring all-or-nothing settlement.
A comprehensive event log records:
Each event includes:
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.
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.
The INTERLOCC Protocol implements defense-in-depth security across multiple layers:
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.
Payment Instruction Validation:
ILO Issuance Validation:
Settlement Finalization Validation:
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.
Purpose: Prevent excessive counterparty exposure by enforcing maximum unsettled obligations between any two banks.
Operation:
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.
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:
Benefit: Ensures operational SLAs, prevents capital lockup, protects customer funds.
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:
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.
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:
Use Cases:
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.
Trigger: Bank agent marks payment as REJECTED during screening
Process:
Customer Impact: Sender receives funds back, recipient never sees payment
Trigger: Governance declares that a bank has defaulted on obligations
Process:
Rare Event: This represents a bank-level failure and would trigger broader industry response mechanisms.
Trigger: Settlement executor fails to execute a ticket within the deadline
Process:
Mitigation: Multiple executor services provide redundancy. If primary executor fails, governance can quickly reassign.
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.
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.
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:
Complete Traceability: Any payment can be traced from creation through settlement, showing:
This complete record enables rapid dispute resolution without relying on potentially inconsistent internal bank records.
The INTERLOCC Protocol provides comprehensive monitoring and reporting capabilities suitable for bank operators, compliance teams, treasury management, and executive oversight.
Real-Time Metrics:
Payment Search & Filter:
Drill-Down Details:
Real-Time Metrics:
Bank Pair Analysis:
Lifecycle Tracking:
Utilization Metrics:
Risk Indicators:
Configuration Management:
Current Window Status:
Historical Analysis:
Net Position Visualization:
Pipeline Status:
Executor Performance:
Settlement Coverage:
Screening Metrics:
Audit Event Explorer:
Regulatory Reports:
For Bank Operators:
For Compliance Agents:
For Treasury/Risk:
For Governance:
For Technical Operations:
Delivery: Automated email, dashboard, API
Delivery: PDF export, regulatory submission format
Delivery: Executive summary, detailed appendix
Custom Queries:
Export Formats: CSV, JSON, PDF report
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.
The INTERLOCC Protocol represents a fundamental reimagining of interbank settlement infrastructure, combining:
For participating financial institutions, INTERLOCC delivers:
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.
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.