This section details considerations made during the design of IFEX in
an attempt to explain the reasoning behind specific design decisions
to implementing or technical audiences.
Transaction protocols such as [HTTP] and [JSON-RPC] were necessarily
avoided on account of their lack of support for arbitrary communications
The IFEX policy of transport and communications topology neutrality
necessitates a broader approach to message identification than classical
[TCP]-based transaction-oriented application level protocols.
This is because the use of unreliable transports AND/OR
broadcast/multicast (one-to-many) topologies MAY occur. At the other
extreme, an IFEX deployment MAY make use of a reliable transport with
bandwidth and latency sensitivity and opt to exclude message
identification overheads entirely.
Financial Transaction ID (FTID)
The Account of Interest Identifier (AOI) is 13 characters to facilitate
the straightforward association of an IIBAN with a transaction; note
however that the use of IIBAN for AOI is NOT required. (Use of IIBAN
relieves IIBAN-based implementations of the need to store the entire
FTID; instead they MAY store only the subsequent (UTCSO and ISTI)
portions against the internal transaction ledger(s) in question.)
The second-level granularity of the temporal portion (UTC Second of
Origination, or UTCSO) was chosen in order to provide a reasonable
mechanism for the immediate association of a FTID with an adequately
specific point in time to facilitate sorting. The day-based granularity
alternative would reduce the overall length of a FTID significantly but
was discounted as a probable cause of increased human error,
particularly on numerous existing systems that MAY operate partly or
wholly upon local timezones instead of UTC.
The length of the Intrasecond Transaction Identifier (ISTI) was set at 5
characters as it rounds out the overall FTID length neatly to 32 bytes
and provides what is felt to be an adequate maximum of 60,466,176
transactions per AOI per second. (Implementors requiring scalability
beyond this number of transactions per second should refer to the
Maximum Transaction Throughput section for recommendations).
It is recognized that a frequent case is that a fee, tax or discount
will affect all settlement paths, for instance jurisdiction-based
taxation usually falls in to this type of situation.
Whilst a mechanism for the description of such cases was considered at a
disparate level to that of settlement paths in order to realize shorter
message lengths (ie. removing the need to redundantly specify the same
fee, tax or discount on duplicate settlement paths), this was ruled out
on the grounds that removing a secondary location within messages for
the specification of equivalent cases was a simplification and therefore
desirable. In addition, the optimization of such cases at the wire-
level is possible to effect through alternate wire-formats (or
'middleware' in today's enterprise parlance), and it has been previously
noted that "Premature Optimization is the Root of All Evil".
While other financial protocols have seen fit to categorise transactions
in to fixed categories, IFEX avoids such a scheme due to its goal of
maintaining a maximum breadth of deployment applicability. This
decision also serves to remove the frequently observed potential for
latter accretion of redundancy in protocols where the sum total of all
future requirements failed to be perceived at the protocol design stage.
The need for specific deployments to include mechanisms for transaction
categorisation is, however, acknowledged with IFEX's capacity for
parties to establish agreed vocabularies of transaction types to suit
deployment time requirements. In addition to more specific and/or one-
time vocabularies, it is anticipated that common common transaction type
vocabularies will be established to cater to repeating industry, market
and regulatory jurisdiction level requirements; possibly even by
industry bodies and/or regulators themselves.
Multiple transaction types are allowed per transaction due to this
perceived need for multiple transaction type affinities per transaction,
ie: local system or deployment linked, industry or market linked, and
(possibly multiple) jurisdiction specific regulatory requirement linked
transaction types may be associated with a single transaction.