LIXItech

CAL 1.4a (finally!)

Well, like all things LIXI, this has taken longer than we'd hoped but a draft release of LIXI CAL updated to support Anti-Money Laundering requirements has finally been published. This is a draft release and member comments are urgently sought to determine if the draft meets member needs. I cannot overstate this - if you are a CAL user you need to review this draft to determine if it is sufficient to enable you to comply with your interpretation of the AML requirements. If we have missed something important the only way we'll know is if you tell us.

LIXI members can view the draft schema here.

This draft is a modification of the CAL 1.4 standard and has been labeled CAL 1.4a. As I've mentioned previously our intention is to publish similar releases to modify CAL 1.2 and CAL 1.3 (CAL 1.2a and CAL 1.3a respectively). This will mean that all CAL users, regardless of the CAL release they are currently using, will only have to make the bare minimum of change to existing systems to be able to comply with AML requirements (e.g. if you are currently using CAL 1.2 you only need to adopt CAL 1.2a - you won't need to upgrade all the way to CAL 1.4a unless you want to). The changes needed to create CAL 1.2a and CAL 1.3a are very similar to those made to CAL 1.4 so these releases will be available very soon after we have confirmed that this draft release is acceptable.

This document describes the changes made to create CAL 1.4a.

This may have slipped under your radar

LIXI Products 1.3* has finally been released. After close to three years work, re-work, and re-work of the re-work followed by starting over and doing it all again. Sigh. But that's all in the past now! The main thing is that it's done and ready for use. If you can't think how to deploy it I suggest you take a close look at the Visible Loans project for inspiration.

The new schema is available for download by LIXI members here, and a User Guide can be found here.

* Observant LIXIphiles may be wondering why a new standard has the designation "1.3". This is because LIXI CAL up to CAL 1.2 included a DTD specifically for product information. It was an odd place to put it, and to the best of my knowledge no-one actually used it, but it was there.

Great minds think alike

This news update was just emailed to NECS stakeholders:

"Industry and jurisdiction stakeholders alike will be interested in a recent development in the UK.

The UK Land Registry, custodian of the world’s largest land register with almost 18 million titles registered, has announced that it has signed up as a member of the e-business standards body PISCES (Property Information Systems Common Exchange Standard) as part of its commitment to electronic conveyancing  PISCES Ltd is a not-for-profit body similar to LIXI Ltd and has been involved in developing and publishing a wide range of electronic data transfer standards for the property industry in the UK and Europe over the past ten years.

The UK Land Registry has been working towards an electronic conveyancing solution since 2002 and its Director of Information Systems, John Wright, noted in the announcement that “PISCES is one of the key drivers behind the adoption of open e-business standards for the property industry, enabling it (ie the industry) to function more effectively and efficiently.”

Like the partnership between LIXI and NECS, the UK Land Registry sees its involvement with PISCES, of which many of its customers are members, as benefiting the development of electronic conveyancing and in particular integration of its systems with industry systems to achieve straight-through processing of conveyancing transactions.

The announcement can be viewed at http://www.landreg.gov.uk/about_us/pressoffice/notices/default.asp?article_id=17192 and details of PISCES are available at http://web.pisces.co.uk/public/about.aspx?ID=1."

If you'd like to know more about Australia's electronic conveyancing initiative you can check out the NECS website. LIXI members who'd like to know more about how the LIXI/NECS collaboration is going can take a look here.

New Year's Resolution: Do Something About CAL 2.0

LIXI aficionados will know that "CAL 2.0" has been mentioned for years as the point at which we break with the past and correct all the mistakes we've accumulated through successive versions of CAL 1.x. While those of us closely involved with CAL at a technical level would dearly love to do a major clean-up the problem has always been the investment many LIXI members have already made in CAL 1.x. There is a substantial constituency for the idea that, "it's not really broke, so why fix it?"

Nevertheless the shear weight of the accumulating hacks and compromises in CAL 1.x will eventually force us to take the leap, and in my opinion 2008 is the year it will have to happen. If you'd like to know more please have a read of this document. It's intended as a straw man so feel free to comment and/or criticise to your heart's content. You can post comments here, in the Loan Application Working Group on the LIXI site or directly to me via email. Note that the document is officially a "Draft" with a version number of 0.1 - it really is intended as a starter document that will only be complete once we have substantial member feedback to include.

Update: The content of the document has been added to the online requirements discussion for CAL 2, so you can embed comments there if you like.

Ah, now I understand...

If you've got 10 minutes to spare this is well worth watching:

More on securitisation and reporting transparency

Given what I said a few days ago about a "Common Reporting Format" to improve transparency for RMBS investors this presentation from last week's Australian Securitisation Conference is pretty interesting. Actually the whole conference was pretty interesting and there's plenty of worthwhile reading to be found in amongst the rest of the conference papers. If you missed it you really should consider going next year.

Looking outside of the box

With loan processing the devil is always in the details, so it can tempting to believe that our market is just too different from other markets for us to learn all that much from how others go about it. But at the end of the day we're all doing the same, fundamentally simple, task - figuring out who's an acceptable risk and who isn't. So it doesn't hurt to take a look outside of Oz every now and then. For instance there's this blog someone just pointed out to me - Rick's Notebook. Interesting stuff, and I love the idea of SOA-based Automated Underwriting Systems that you can hit from your own processing platform for a second opinion or for a specialist assessment of a particular type of deal. Intriguing idea, and of course SOA's work best in a standards-compliant environment, like that provided by LIXI...

Oh, and this one's interesting as well, given some of the claims we heard recently at the LIXI Mortgage Industry Forum.

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...]

Australia's Next Top (mortgage insurance) Model

[This is a cross-post from the LIXI Mortgage Insurance Working Group. The MI Group has been inactive for so long that I expect there are people who aren't signed up to it who nevertheless would be interested in this topic.]

Some of you will be aware that we've been developing a business process model of online mortgage insurance as a prelude to developing some LIXI standards in this area to replace and improve upon the current ad-hoc usage of LIXI CAL derivatives. The model is available for review and we'd welcome feedback on it.

The model is very simple as it focuses on normal, high-volume transactions and does not try to capture less common transactions. Interestingly the model suggests, to me at least, that defining some LIXI standards in this area should be a very quick and simple project. If you consider the transactions required (dashed lines in the diagram) they appear to boil down to:

1. A MIRequest - this would need a Type attribute to distinguish between requests that are for simulations vs. actual commitment requests and to distinguish initial requests from additional-data and modified requests. It should also be "batch-able" to support scenarios where the MIRequest is really a notification of deals insured over a given period under DUA. But in any case the total number of new fields we need to define in the standard is minimal because the vast majority of data can be handled by allowing LIXI/CAL (and LIXI/Valuation?) instances as included or attached payloads.

2. A MIResponse - which is very close to being just another backchannel message, so we could create it by copying and only slightly changing the existing CAL 1.3 Response schema.

I'd be very interested to hear from anyone who thinks it's really more complicated than this. The only major wrinkle I can see at the moment is the question of how physical documents (by which I mean images of physical documents) can be exchanged - but that's a bigger question of relevance across many LIXI standards.

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.