LIXItech

LIXI and Securitisation

I spent the last couple of days attending the Securitisation Professionals Program put on by the Australian Securitisation Forum. A great course BTW, and highly recommended for anyone who wants to get their head around the basics of securitisation. But of course my perspective was very much a LIXI one and my head is now full of intriguing thoughts...

Securitisation is a big topic but a couple of key points stood out for me. First and foremost was the importance of having plenty of rich and timely data. Transparency is something that is highly valued by investors and by ratings agencies, and thus is something that can make a big difference to margins. This is particularly true for offshore investors who need extra assistance to get comfortable with Australian product. Yet the comments made by lecturers from the investor side were that data quality and timeliness typically leave a lot to be desired - a problem seriously exacerbated by the fact that data sources (originators and services et al.) don't have a consistent reporting format or even a consistent interpretation of the meaning of basic concepts like "arrears" or "default".

It appears a Common Reporting Format (CRF, to coin an acronym) would be a Very Good Thing and needless to say I think a LIXI-based CRF could be the way to go. I have a few starting assumptions in mind:

1. A LIXI CRF should be as simple, and as low-level, as possible. By which I mean it should address the raw data only, and at a loan-by-loan level. Any interpretation and aggregation of the data should be left to the data recipients. For instance it would be sensible to capture the LVR of each loan in a pool, but we shouldn't try to capture interpretive or derivative information (such as the expected default rate for loans of that LVR, or average LVR's across the pool, etc.).
2. We should, however, make it possible to capture the basis on which the raw data has been determined. For instance it is not sufficient to simply flag a loan as being in arrears by x days - you need to be able to specify that the time in arrears has been calculated by counting from the date of the last payment, for instance. The obvious point of comparison is the LIXI Commissions standard where we don't just capture the commission amount, we also capture the commission calculation basis.
3. A large proportion of the data required is already defined in the LIXI Vocabulary (e.g. details about loan types, property types, borrower types, etc.) but careful documentation of the meaning of terms in the context of the LIXI CRF will be essential. If we use a term we not only need to know precisely what we mean by that term we also have to make it easy for non-LIXI parties (e.g. offshore investors) to discover what we mean.
4. Despite what I just said in point 3, we need to avoid over-complicating things. A perfect solution might be built on XBRL for example, but my guess is it would take a very, very long time to become commonly used due to its complexity and the fact the lending industry has had very little prior exposure to XBRL. A LIXI CRF, in contrast, would be a "good enough" solution that could be quickly piggy-backed onto existing systems and processes for loan processing and back-channel reporting.

At present I'm envisaging something built on a mix of LIXI CAL plus the planned LIXI Loan Servicing standard, but structured like the LIXI Commissions standard, i.e. line-item reporting of self-describing raw data. With support from the right parties (Perpetual Trustees springs to mind for a start...) I think we could get something done quite quickly, and it would be relatively easy for lenders and servicers to adopt because it would be mostly just stock-standard LIXI data. The payoffs, for all parties the length of the securitisation chain, could be huge.

[Of course this could all get done much, much faster if we had the LIXIpedia in place already. But I've made that point before in another context...]

LIXIpedia

I spent the afternoon a couple of days ago with the guys at NICTA looking more closely at the "LIXIpedia" concept (as first mentioned on this blog here). For those that haven't read the proposal document the basic idea is to change LIXI from being a top-down, consensus-driven and chronically slow institution into something dramatically more responsive. The way I'm suggesting we do this is by turning the LIXI Vocabulary into something like Wikipedia, where everyone gets the chance to add whatever they think the Vocabulary needs. Sounds nutty at first but I'm not suggesting an uncontrolled free-for-all - there would be rules to keep things sensible.

The point of the session at NICTA was to kick off a research project to figure out exactly how a LIXIpedia would work in practice. It's an interesting experience to sit in a room full of Ph.D's all saying, "yes, but..." about your pet idea. Thankfully the concept (and I) survived the experience, though it certainly gave me plenty to think about. Some of that thinking can now be found in a new version of the proposal document, available here. Probably the single most significant change is that it's become clear that Wikipedia is not an ideal analogy. In the Wikipedia world there is one current truth, albeit one that changes constantly, whereas what we need is support for multiple concurrent truths. For example if one or more LIXI members want to change the definition of "Address" I believe they should be able to do so, but the original meaning of "Address" must continue as an equally valid term in the Vocabulary to support all the members still happy with the old definition. In other words, the rule needs to be that you can add pages to the LIXIpedia but you can't change existing ones. If you add a page by copying and modifying an existing page that, practically speaking, requires a kind of versioning - not because the parentage of a page matters, but so you can keep using meaningful names. For example the element "Address" needs to automatically increment from "Address_0" to "Address_1", "Address_2" etc. as people create more LIXIpedia entries that are intended to capture address data. But this isn't really the right place to get into the finer details. If you're interested please read the proposal, and if you have any opinion about it or suggestions for improvement you are welcome to post comments here.

BTW, the name "LIXIpedia" is just a working title and not a very good one at that. The imperfect analogy with Wikipedia is only one of its problems. We really need a different name that could allow for the fact that a shared, collaboratively-edited vocabulary for financial services e-commerce could easily end up covering a lot more than just the lending industry. Maybe we should run a contest to find a better name. I'll start things off by offering my old 2nd gen iPod as a prize. I'm pretty sure it still works.

Anti-Money Laundering - not that hard?

The draft requirements for changes to LIXI CAL to support AML laws have been up for a while now and appear to be reasonably stable. So I've gone through them to try to figure out exactly what sort of schema changes will be required to each of CAL 1.1, 1.2, 1.3 and 1.4. It all looks pretty straightforward, which is encouraging but I'm still concerned that some of the apparent simplicity is only a reflection of the fact that many LIXI members still haven't really looked at this problem yet. I suspect that, as has happened in the past, we won't get the real requirements until some real-world implementations are rolled out. Which means CAL 1.1a, 1.2a, 1.3a and 1.4a will quickly have to be replaced by a CAL 1.1b, 1.2b, 1.3b and 1.4b. That's one hell of a lot of stuffing around.

Needless to say I wish we had the LIXIpedia in place all ready...

Thinking different

One consistent message that came out of the LIXI Industry Forum was that members want us to "do more". The precise nature of the more we should be doing is a little harder to discern but, clearly, LIXI's achievements to date have simply whetted everyone's appetites. The problem from my perspective as the guy who's got to find a way to deliver on all these heightened expectations is that LIXI's productivity over recent times has been trending down, not up. The greater the range and complexity of the processes LIXI impacts, and the greater the numbers of implementations of LIXI-compliant systems, the harder it is to make sure that new initiatives don't adversely effect past initiatives. Ironically LIXI has a legacy problem. And unfortunately that's just one of quite a number of problems that add up to a real headache if the goal is to enable LIXI to deliver more and to deliver faster.

A short while back I put together a short document outlining the situation as I see it and a possible solution. Download repositioning_lixi_1_1.pdf A little bit radical-looking at first sight but my feeling is that we have to do something, and if not this than what? (That's not a rhetorical question by the way - I'm genuinely interested to hear alternative suggestions.)

The status of my proposal at this point is that I've circulated it a bit informally and at least some LIXI Board members have read it. Generally speaking the feedback has been positive but with something this important I think we need as wide an audience as possible, and ideally that audience will speak up to let the LIXI Board and myself know what they think. Happy reading!