Certain functionality required by modern financial systems is not
presently available in open, legacy-free, adequately globalized
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.
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
* 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.
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
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.)