trade-brainstorming
Specification
Introduction
There are many examples of financial transactions across the web and in desktop applications, including bank statements, purchase receipts, wishlists, PFM applications, etc. A standardized format would facilitate integration between vendors, financial institutions and applications to provide for far more robust financial accounting integration.
Format
There are many data formats used in financial systems to represent transactions. The vast majority of these are proprietary, typically resulting from an evolution from paper-based accounting to mainframe computing to electronic interchange networks to the web and now to mobile systems.
In General
A simple semantic format using (like hCard) object/property names in lower-case for class names. Financial transaction attributes would be mapped to nested XHTML elements.
Root Class Name
The root class name could "record". "Record" is a common financial industry term. Records map to all data collected in the form of a "transaction". The expression of a record is itself considered a transaction.
Properties and Sub-properties
The properties of a trade are represented by elements inside the trade root. Elements with class names of the listed properties represent the values of those properties. Some properties have sub-properties, and those are represented by elements inside the elements for properties.
Property List
properties (sub-properties in parentheses like this)
Required:
- post-date
- to-account (to-account-number, to-account-holder)
- amount-posted
Optional:
- date (date-type)
- from-account (from-account-number, from-account-holder)
- date-hold-start (date-hold-end, amount-held)
- status
- type
- reference-number (card-type, periodic-rate)
- fee-amount (fee-type, fee-description)
- category-name (category-id, category-amount)
- image-type (image-front-url, image-back-url)
- tax-flag (tax-flag-type, tax-flag-amount)
- return-url (return-description)
Singular vs. Plural Properties
Singular properties: 'post-date', 'from-account', 'from-account-number', 'from-account-holder', 'to-account', 'to-account-number', 'to-account-holder', 'amount-posted status', 'type', 'card-type', 'periodic-rate'. For properties which are singular, the first descendant element with that class should take effect, any others being ignored.
All other properties can be plural. Each class instance of such properties creates a new instance of that property.