Our Proposals‎ > ‎

IFEX Protocol

The Internet Financial EXchange (IFEX) protocol facilitates the negotiation of financial transactions between internet-based financial endpoints.

Status: currently under development. Last updated: 2013-09-09.

Problem Statement


Certain functionality required by modern, forward-looking financial systems is not presently available in open, legacy-free, adequately globalized protocols.

This functionality includes:
  • Negotiation
    • Prescriptive quotations
    • Settlement and reversal / cancellation / contract exception terms
    • Exchange rate negotiation / hedging
    • Fee, tax and discount calculation / negotiation
    • Trust facilitation (eg. escrow, hedging via third party derivatives)
  • Arbitrary currency / asset support
    • Conventional currencies, emerging currencies, currency-like commodities, commodities, even services
      • Significant latent interest in the emerging 'cloud', 'smart' or 'distributed' manufacturing sector, partly driven by the growth of 3D printing and partly driven by calls for increased efficiency within existing manufacturing supply chains
    • Multi-currency / asset transaction support
      • Reportedly widely used by agents in the global maritime shipping industry to hedge exchange rate risk across multiple conventional currencies
  • Arbirary settlement path support
    • Multiple concurrent settlement paths
      • Provide for increased availability through fault-tolerance in financial settlement
    • Support for in-band settlement (sometimes known as DVP)
    • Settlement latency calculation / negotiation
    • Multi-hop settlement path support
    • Arbitrary financial settlement topology support (including multi-hop, multi-party)
  • Hard to find features
    • High precision decimal value support
    • Arbitrary communications topology support
      • Full support for n:n topologies such as those used in high availability or high frequency trading (HFT) systems
  • Security
    • Integrated cryptography for message authentication and integrity
      • Enables reputation metrics, publishing contract excerpts for 'name and shame'
Given this situation, it makes sense to propose an open, legacy-free, adequately globalized, extensible protocol for internet-based financial exchange.

Work in Progress


General idea: a stateful message-oriented protocol, based upon JSON, that normalizes financial transaction identification and state transitions (initial, pending, settled, success, failure, partial) across disparate settlement systems.  Supports arbitrary topologies and transports, aiming for significant extensibility, and keeping the overly specific stuff (used only in some financial messaging scenarios) out of the core specification.

Settlement paths over arbitrary settlement networks can be compared by individual IFEX Nodes based upon hard data regarding the settlement path properties that is supplied by the settlement provider(s) in QUO (quotation) messages.  Such messages may be sent in response to RFQ (request for quotation) messages.

An IFEX Node might then send execution (EXE) messages to initiate the settlement of a financial transaction, tracking its progress through the normalized state transition mentioned above.

In computer science terms, the protocol hopes to implement something akin to the Paxos algorithm or or Chandra–Toueg consensus algorithm, optimized for a financial transaction use case.

In this sense, the IFEX Protocol hopes to create a fair and open market for financial services with the capacity for real time, intelligent routing based upon real route (settlement path) characteristics - fostering interoperability and removing barriers to communication, something like IP did for networking, or SMTP did for electronic mail.  It also serves to support real time redundancy and failover for high availability financial services.

Related Projects

  • Bitcoin
    A cryptographic system that functions as a combined settlement network and digital currency.
    Website: http://bitcoin.org/
    Integration Outlook: Bitcoin is a prime use case within the IFEX requirements and will be fully supported as both a settlement network and asset denomination
    (X-ISO4217-A3: XBTC).
    Differences:
    • No attempt to cover the settlement of alternate assets. (Though numerous third party currency markets / exchanges provide these services.)
    • No internal attempt to integrate with other systems. (IFEX should help.)
    • High minimum latency threshold. (IFEX should help by providing automated negotiation of settlement latencies, which can be reduced through the use of trusted Bitcoin exchange sites)

  • W3C Web Payments
    Hosted by the World Wide Web Consortium (W3C), this effort focuses on removing barriers to and enhancing the user experience of web based commerce.
    Website: http://www.w3.org/community/webpayments
    Integration Outlook: Potential for IFEX to provide backend services to PaySwarm authorities as a means to integrate W3C Web Payments with existing settlement infrastructure. (Source: Private telephone communications, 2012-04-12)
    Differences:
    • Scope significantly narrower. (Major focus is B2C, web oriented, point to point transactions)
    • Scope directly includes user experience considerations.

  • Ripple Project
    The Ripple Project is presently designing a protocol for the connection between various ripple exchanges. In late 2012, it was announced that this was being commercially backed by OpenCoin, Inc. in San Francisco and development has moved to the commercial domain ripple.com.
    Website: http://ripple.com/ (current) and http://ripple-project.org/ (historic)
    Integration Outlook: Ripple should be fully supported. Significant dialog with the Ripple project team, including code sharing.
    Differences:
    • Ripple seeks to provide many services, though chief to this are the two core aspects of a fee-possible system based upon a blockchain system for 'Ripple Credits' (X-ISO4217-A3: XXRP) not dissimilar to Bitcoin but with non mining-based distribution, and the decentralization of credit creation.
    • Ripple does not appear to approach many aspects of IFEX such as business level metadata, <n>:<n> messaging topologies, or problems of exchange/interoperability with other systems.
    • IFEX could help to complement Ripple's own properties as they emerge by providing solutions to many of these peripheral issues and providing a standardized means for interoperability with other settlement systems.

External Links



The following general links provide information around conventional, emerging and proposed payment protocols and systems that are of potential relevance to IFEX development.
  • General Payments Environment

    • Protean Payment: Recent, US-centric analysis of innovations within the commercial payment systems environment, with a mass consumer payment system focus, by a Michigan-based startup.

  • Bitcoin-linked

    • Bitcoin Payment Messages, Gavin Andresen. Evolving as of late December 2012.
      A somewhat controversial effort by the Bitcoin development community to resolve some of Bitcoin's quirks through the addition of yet more steps and complexity in Bitcoin-based payments:
      "This document proposes protocol buffer-based formats for a simple payment protocol between a customer's bitcoin client software and a merchant. Separate documents will propose an extension to the Bitcoin URI syntax and new MIME types to support them."

    • Beyond IP Transactions: towards a payment protocol, sipa, ~late 2011.
      "What current addresses are, is a reference to a public key. The way they are used is as a template for a transaction. If you do not need complex transactions, this suffices indeed, given that all other negotiation about the payment occurs out-of-band already (e.g., a webshop interface that after clicking 'pay' gives you a freshly generated bitcoin address and stores it so it can track your payment). What I want to do is to standardize part of that out-of-band communication inside a protocol. [...] Summarized: addresses are a limited method for defining payments, and as soon as you move to a protocol instead of a static template, a lot of possibilities open up."

    • Homomorphic Payment Addresses and the Pay-to-Contract Protocol, Ilja Gerhardt & Timo Hanke, 2012-12-13.
      "We propose an electronic payment protocol for typical customer-merchant relations which does not require a trusted (signed) payment descriptor to be sent from the merchant to the customer. [...] The protocol is specifically designed with bitcoin in mind as the underlying payment system."