Paul -

>
> The key, it seems to me, is having systems in place to validate both data and the mark-up language. As I understand
> XBRL, it's easier to write rules to validate data in that format than in other popular formats. And an XBRL taxonomy can
> be crowdsourced, reviewed by experts, crowdsourced again, etc., in a never ending cycle to improve the taxonomy.
>

I acknowledge there is a lot of enthusiasm for taxonomies & ontologies.

Particularly in financial services I do not concur.

The whole idea of taxonomies is from natural science where Mother Nature has had 100s of millions of years to organize things.

Financial institutions are sometimes 100 years old (very few) & maybe a few decades old.

Financial institutions have been cobbled together in a totally higgeldy-piggeldy fashion, with no road map or sense of order.

The idea of there is a hierarchical order of concepts & data inside these organizations is fanciful at best.

I have no experience with whether or not XBRL has easy to write data validation mechanisms.

The real problem is at the "source systems" inside the companies. Because these organizations have typically been cobbled together so haphazardly over the decades of mergers & lurching from market fad to market fad there are normally multiple sources of "the truth."

More eyeballs on the data is very important.

Why accounting firms have been so useless (did they learn anything from Enron?) is something of a mystery to me. At least in theory they represent extra eyeballs.

- David

Paul -

I too was impressed by that Hernado de Soto essay. Strong agreement from me.

But now there's an additional layer BENEATH the paper documents. Now the data flows through a variety of sort-of computerized mechanisms before it hits the paper document.

I can't help but remember Robert O'Harrow's description in "No Place to Hide" of how real estate ownership/court judgements data was harvested from court houses for the credit bureaus. (1) Manually record court house data on paper, (2) rekey said data into a PC, and (3) ship data to the credit bureaus. Clearly a process ripe for errors.

No wonder my wife ended up with a spare husband.

Or this, that happened to me. At some point I got my 3 credit reports: Two of the three had problems with my address. One had a wrong zip code on the address/cover sheet & correct zip code on the actual report. The other was just the reverse: correct on the cover sheet & wrong on the report.

Two observations. Zip codes changing (which had happened to me) is NOT news. These reports were something like 5 years after my zip code had changed. These credit bureaus (BIG organizations with lots of computer power) didn't have a process to correctly deal with changing zip codes. I can certainly see such laxity in the handwritten court house registries, but not at the credit bureaus.

Somewhere someone's going to have to vouch for the quality/accuracy of the data produced by the organization. Which means they're going to have to audit the data they produce, particularly if it is presented to the outside world. Now THAT is going to be interesting.

A major reason that de Soto's essay resonated with me is that 30 years ago I worked on a banking application (Letters of Credit - LC) using a tag based language (e.g. like XML). Much of the documentary output of an LC system is actually legal contracts. Then as now, most of the output from computer systems is simply reports. If a report is wrong, you re-run it. If your broker bungles a trade, no problem... simply back-date the trade & send a new confirm.

All this is why I'm cautious about this XBRL stuff. Who's going to assure that the contents are accurate & truthful? The Enron accountants? Having scratched the surface of the 1980s Saving & Loan fiasco (hmmmm... similar to today's mess?) I'm pretty much a believer in "control fraud."

From what I've seen of information systems, there's far too much data to be useful/accurate information. Hence, management gets to pick & choose what "information" is useful to prove their point, make their bonus.

- David

Dennis -

>
> private data
>

Yet another aspect I hadn't considered. My experience was with "private to the organization" data, not private data purchased from vendors.

No matter... still fits into this story. In the early days of the Industrial Age (late 1700s), aside from the fact that machine tools were so crude they couldn't make stuff consistently, a lot of machinery was entirely custom to that manufacturer. If the customer needed repairs/replacement parts they HAD to go back to that manufacturer. Nice little monopoly. Goes to show that neither IBM, or Microsoft were the first to play this particular market control game.

Eventually it took 75 years to agree on common screw thread standards. I believe there are still 5 "standard" screw threads in the UK today.

I'd like to think that XBRL is a push to standardize (not entirely sure what that means yet) financial data. Currently tons of financial data means what it means to the publisher & if it means something else to you, well that's your problem, not the publisher's. This is obviously not good.

___________________

I'm now aware of at least 4 industries that are under pressure to "do better" with their data:
- the intelligence community ("connecting the dots")
- financial services
- healthcare (Electronic health records)
- food production/processing (Interesting TV piece last night where David Kessler, former FDA jefe, said whereas the food industry had historically resisted improved reporting/regulation, now they've turned around, since stonewalling is clearly bad for business.)
____________________

What I'm looking for (is XBRL the answer, or a partial answer?) is a mechanism for a piece of data that ensures that the label is meaningful (this is not the same as saying there is ONE & ONLY ONE name for a thing) & the content is tightly in sync with the label. Examples: When I go to my mail box, I reliably find my mail, not someone elses. Likewise: when I got to the supermarket & to the milk chest, I find milk in milk bottles, not motor oil or orange juice.

For anyone who's been inside systems, obviously this level of consistency & standardization is only a remote dream.

- David

Dennis -

Never knew CUSIP's were private.

I dimly remember having them around in the mid 70s during the kinda early days of mutual funds. Never gave a thought as to who "owned" a CUSIP. Odd.

Back then I actually remember having to print out certificates now & again. How's that for ancient history!

More currently, when I got a liar's loan in 2001 from WAMU, it was TOTALLY clear to me that whatever alleged process was behind the application "system" was a total shambles. I could only think about how little organizations had learned about the basics of data collection, verification & quality. Clearly a new generation was making it up on the fly. Sure wish I'd followed my instincts & shorted WAMU.

- David

Dennis -

Ok, "deal modeling" it is.

Since you bring up UML, just how is this "deal modeling" done? Someone pulls together a UML model & then....?

Or is the process mostly done in spreadsheets since folks are running around to much to sit down & really think through what's happening?

I haven't been following UML closely enough to know if its gotten to the point where you can compile the model into running code. My point being that models quite often are a form of documentation. Someone works very hard on it to get signoff, but then it fundamentally goes on the shelf & the running code becomes the only Truth. The problem with code being the Truth is that only programmers can read code & they're kept out of the loop as to the business purpose of what they're writing.

- David

Dennis -

Interesting. Perhaps things are done differently on the West Coast.

I am more than happy to argue that ONE of the contributing factors to this financial mess is that the MoUs (masters of the universe) who run things do NOT learn about systems in business school. I verified this with a friend who has taught TOM (Technology & Operations Management... likely what my father had) at Harvard. TOM is a required first year course. It gives a non-threatening 200,000' fly-by of systems.

When I say "systems, I do not mean teaching Java, PHP, or COBOL to MBA students. I mean teaching that things are interconnected in bizarre & unknown ways, particularly inside the rats nest that is the enterprise information systems portfolio.

It is my thesis that they teach finance/accounting in MBA programs because it's easy. And they do not teach systems because that is hard.

To bolster my position, I offer what Peter Drucker said many years ago: "...to treat finance/accounting & systems as two separate & unrelated academic & career paths is unacceptable."

Back to the current day, HBS & TOM... another reason they don't teach systems at HBS is that there's no one to do it... all the famous old goats have retired.

Another observation... when MoUs do their MBA thing since systems are ignored, this by definition conveys the message that systems are unimportant. That's what CIOs are for. It's like in the Army... if they wanted you to have a wife, they'd issue you one. Not issued... ergo, not important.

I asked a friend today if "data management" is taught at the service academies (e.g. USMA, USNA, USAFA, USCGA) & he thought not.

- David

Dennis -

>
> MBS/CMO deals are part data records and part deal modeling language
>

Is "deal modeling language" what you meant to say, or is it a typo for "data modeling language?"

Until corrected I'll assume "data modeling." "Deal modeling language" returns 3 hits on Google.

Unless something drastic has changed, the problem with modeling systems is that what you get is just that... a model, a tiny glimpse into a MUCH bigger whole. Someone then takes the model & converts it to real code (maybe they write a specification in between). The code is then what gets modified & the model goes on the shelf to gather dust.

I'll certainly check my sources, but I certainly wouldn't look to the DoD for working on this challenge.

If I were in charge & running the world, I'd make sure that the top business schools are teaching the future masters of the universe about systems, data, & impact analysis... something that is absolutely NOT happening today. Data is for geeks.

- David

If this has the force of law (e.g. the SEC), it appears to be a solid first step in the right direction.

Bolgiano's paper effectively points out that the financial services firms involved in the MBS market were entirely clueless when it came to their information systems and passing (alleged) information to additional interested parties.