Financial Services DTF wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== WS3 Rolling Notes Thursday 08 September 2011 ======
back to [[Shared Semantics]]

===== Agenda =====
  * REA Ontology - definitive one?
  * Review existing REA terms against the slides
  * The interface between REA and XBRL concepts

===== Progress (Rob) =====
Email sent to Bill MacCarthy and Guido Geerts
 - references ISO 15944 and REA OWL Ontology
 - what other references we should be looking at. 

Reply awaited.

Guido (last month): developments on academic side. Gailly's work is most developed but no normative representative version / ontology for REA. 

Been looking for this stuff. 

MB get back to Frederik Gailly on what he sent me. 

Overall: WE need to do due diligence on what has been constructed non normatively, and find what can be regarded as a normative version out there; however is GG not aware of such, we can safely assume there isn't. 

Action: MB put the Gailly stuff received to date, onto the Wiki. 

===== REA v Accounting =====
REA: Business transactions
Accounting: financial record keeping

So: Accounting txn related to a real txn in real life, but are different. 

One is a speech act and the other is a recording of a speech act. 

==== Business Txns versus debits and credits ====
Business txns - additional kinds of fact such as terms of service and so on. 
Entry in accounting journal is part of this larger process. 

==== Interface: ====
 
Record keeping not the same as making a business deal. 
But
Is that not simply trivial. Model is not the subject; account ledger entry is also not the subject. 

What is the difference? 
Say, XBRL (as surrogate for accounting entries). REA as perspective on the transaction. It summarizes the transaction but does not take a point of view. 

Is this true? REA shows two points of view, not none. 

REA: "There has been a txn, A has dealt with B"
Accounting: "I am A, and am reporting this txn"; also I have to balance this within the closed environment of my accounts (double entry), so if I have parted with one asset, and don't (yet) have the other side, then the value of the business has risen or fallen to balance this, closing out the txn. The REA context does not care about that. 

Another way of looking at it: All financial txns, the financial consequence is picked up by the journal entry; this follows the same format as the REA txn. But part of the txn you don't care about (details as seen by the other party). In a subsidiary ledger, you would care who the other party is (details of the txn including the counterparty, as reflected in the existence of the subsidiary.

Legal: define commitments. Amount to agreed liabilities in the future. Discharged (or not)
Accounting: have a position at any given time.

So we could say that REA records the legal reality and accounting records the positional reality. 

If I enter into a forward transaction, even if not due today, I would still record them today in my accounts, as a forward commitment. 

Nowadays we don't always record these into subsidiary ledgers. 

=== How is this recorded? ===
 Create a different ledger account e.g. "Forward commitments to pay" or something. Also a "Forward right to receive" ledger. 

At some date in the future, those that were future transactions become current assets or liabilities when that date comes. 

Example: Fx: record the forward commitments. Can revalue. Accounting conventions exist for this. Transparent to XBRL, it's just a name of a ledger.

Does this mean you are choosing to record future liabilities. You would choose to record a liability in the future, today. Likewise a payment due to come in from someone can be recorded as a future asset. Can record those in a ledger. 

e.g. in Fx would debit forward receipt of USD and credit the AUD value of the value I have the right to receive. 

=== So to the Interface ===
REA: commitments
Accounting: the liability. 

===== Model Implementation =====

Take the commitment in REA and have a relationship fact which points to the Accounts Receivable or Accounts Payable ledger accounts. 

==== REA: See Slide 5 (ref 1): ====
 The Inside Participation and Outside Participation references for each "side" of the transaction, correspond to ledger account entries, i.e. the business fact which is the "Inside participation", is reflected (in accounting terms) in the ledger account for Accounts Receivable. 

Also: 
Side: this reifies the "From" and "To" relations in the REA UML diagram, which go between Economic Event and Economic Agent. 

The commitment summarizes your journal entry. Or doesn't your journal Entry summarize (and formally report on) your commitment. 

Commitments are inherently unstable: you may or may not fulfil it.

Payment: makes a transition to a stable state. (from a liability to a settled commitment). 

Also NB a commitment may be settled in one of many ways. The existence of a liability doesn't prescribe how the liability will be discharged. It may be discharged by paying in cash or in kind - for example if the contract allows for either; or as part of reparative actions. 

There are various ways in which a swap may be paid, e.g. by cash payment or by delivery. Delivery: where some collateral changes, and an arrangement is entered into.

Common law and statutory adjuncts to standard contracts e.g. if the contract obliges A to pay B, in a court it may be discharged in different ways, e.g. spread payments, could agree to pay a different amount, or may discharge it through bankruptcy. 

So even when in the ledger you have the notion of some future potential liability or receivable, that particular future transaction also needs to be tied to the corresponding contract language. It may not happen the way you expected when you put it in that kind of ledger that Max described earlier. 

What you are describing in these future ledgers is the existence of the liability in the future, not the ways in which that liability may be dischared. 

Ledgers don't record the contractual provisions. 

Connection between receivables and payables in the ledger and the corresponding contract: needed for risk analysis. Software in information warehouses may be used to perform statistical analytics to determine the likelihood that a particular kind of default may occur. 

Such software has an implied ontology that will have reference to terms both in REA / Contract terms, and ledger / XBRL terms. 

The amount of money you need to pay e.g. next week is based on the difference between accounts receivable and accounts payable. If not you are going to default. 

==== So: ====
1. We've established the relationship between the contractual reality reflected in REA and the accounting language which reflects it; 

but also: 
Conditions. Whether or not a given condition has been met and so on. 

=== Two aspects to the conditions: ===
 
1. The establishment of them in the language of the contract
2. The unfolding of these in real life. 

On (2), there is the unfolding of things in reality, based on market conditions, behavior of the parties, including defaults and so on. 

==== Master Agreements ====
There are more kinds of this. Examples of covering agreements in insurance and so on. The term labeled Master Agreement here is all such covering agreements (maybe we should rename it Covering Agreement)of which the ISDA type of MA for OTC Derivatives is one such.
Financial Services DTF wiki

User Tools

Site Tools

Page Tools
