Requirements

Problem Statement

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

   This functionality includes:

    * Settlement and reversal / cancellation term negotiation
    * Exchange rate negotiation
    * Latency calculation / negotiation
    * Fee, tax and discount calculation / negotiation
    * Arbitrary currency / asset support
    * Multi-currency / asset transaction support
    * Quotation support
    * Multiple settlement path support
    * Optional support for in-band settlement (sometimes known as DVP)
    * High precision decimal value support
    * Arbitrary financial settlement topology support
    * Arbitrary communications topology support

   Given this situation, it makes sense to propose an open,
   legacy-free, adequately globalized, extensible protocol for
   internet-based financial exchange.


Use Cases

  Primary Use Cases
  Primary use cases may include the following:

    * Internet transactions between parties with no prior
      relationship, where identities and credit are potentially
      based directly upon participation-driven, agovernmental
      community mandate and irrespective of physical legal
      jurisdiction(s).  (For example via [BITCOIN], [CES] or
      [RIPPLE])

    * The owner of market-consolidated assets such as corporate
      stocks negotiating their sale on a market or off-market
      alternate trading system (ATS) or electronic communications
      system (ECS), possibly via one or more brokers.

    * Notification to various bank systems of the physical deposit
      of various denominations of a conventional currency at an
      automatic teller machine (ATM) against an existing account.

    * A direct debit instruction sent from a merchant to a
      particular customer's bank, including reference authorization
      information, possibly via a payment processor, describing an
      amount to be debited from the customer and credited the
      merchant or a third party.

    * A consumer to bank/broker request for the purchase of one
      conventional currency asset with another (foreign exchange
      service).  In addition, prerequisite quotation services.

    * Consumer to bank/broker request for quotation on the
      delivery of assets to a third party account (identified via
      [IIBAN], [IBAN] or some other means) elsewhere in the world.
      Responses to such requests may include multiple viable
      settlement paths with differing fees, temporal parameters
      (execution speed, availability), reversal/cancellation terms,
      legal jurisdiction traversal, etc.


Edge Cases

   Research in to existing protocols and their ecosystems highlighted
   the fact that various non-core functionality often occurs alongside
   financial transaction negotiation processes.

   Such functionality includes:

    * Transaction description/notification (as opposed to negotiation)

    * Notifications and messaging variously regarding financial assets,
      transaction status, financial parties and systems.

      Classic examples include corporate action announcements sent to
      markets, stock split or shareholder meeting notifications, and
      market-wide or instrument-linked trade suspension and resumption.

      (Certain situations such as dividend cash payout/re-investment
      preferencing may require two way messaging and as such exceed
      a pure 'notification' notion.)

    * Shareholder transparency inquiry procedures in which a series
      of tiered requests and responses regarding asset ownership
      information may be triggered by a market authority.

   The approach taken in the design of IFEX has been to increase the
   descriptiveness of the base protocol to reduce the number of such
   edge cases where possible.  (For instance, market availability may be
   described as part of the temporal parameters of a financial
   settlement path.)


Soft Requirements

   Soft requirements include:

    * Maximizing the number of potential of problem domains for which
      the protocol may be successfully deployed.  (Best seen by way
      of contrast with established protocols' general industry segment
      orientation, eg: FIX's market orientation, OFX's consumer
      orientation, and SWIFT's institution orientation.)

    * Minimize assumptions regarding protocol transport, security
      encapsulation, and pre-existing trust relationships.
      (Flexibility in this area allows for the establishment of trusted
      channels with minimal wire-level overheads to support potential
      deployment to highly latency-sensitive environments such as high
      frequency trading (HFT) systems.)
Comments