About a year ago, I did an informal survey of F&I product providers. They were, and still are, moving toward a service-oriented architecture that prints forms and originates contracts online. For providers who do not have a forms service, Provider Exchange Network will host forms at a nominal charge. We offer this as a convenience, even though providers are moving away from it.
Lenders, however, are not moving in this direction. This is mainly due to stricter regulation of finance contracts, and also the disparate experiences of the two groups. In the late nineties, finance sources – both captive and independent – developed online credit systems. They subsequently moved to aggregators like Dealer Track, and many single-lender systems shut down.
So, while product providers have retained their online systems, and support their own services for e-contracting, most lenders do not. This is why my colleagues in Lender Services are busy loading their forms library, while we are unloading ours.
Here’s a tip for designers of F&I software. The way to win a feature-function debate is to challenge the other guy’s understanding of the process – “when, exactly, is the dealer going to do that?” A surprising number of design decisions are made with no attention to process.
Standalone product portals are just one example, where the F&I manager has to break his flow for a one-off activity and some extra keypunching. By the way, pretty much every downstream system must have a DMS interface.
Among experienced designers, two techniques are successful. One is to have a thorough understanding of the process. Does he print the menu first, or the finance contract? The big DSPs have people who study this all day long, on videotape.
The other technique is to design your software to work with more than one process – nonspecific, or “agnostic” in the vernacular. This is not an excuse to duck process decisions. On the contrary, you have to choose specific decisions not to make, and then design for various uses. For example, MenuVantage can read an existing deal from the DMS, or create a fresh one and insert it. It takes extra programming to support both processes, but it overcomes a likely objection from the dealer.
I have just published a white paper on DSP integration for F&I providers. This builds on an observation I made while working at GMAC Insurance last winter. Rather than struggle with a DMS interface, providers should develop their own web services – and let the various point-of-sale systems come to them. This is much more efficient, and good SOA practice besides. Click here to download the paper, or visit the Virag Consulting web site.
I have been polling my friends in the F&I Products industry, to hear their thoughts on DSP integration. In general, they report obstacles at the dealer level and lower volumes than anticipated. The growth in web services continues, of course, with scattered outbreaks of SOA.
What I mainly wanted to hear about was forms management. GE was the first, in my recollection, to provide completed contracts using their own web service – and this is now the trend. It seems increasingly unlikely that providers will hand their forms over for administration by a DSP.
About a year ago, I advised GMAC Insurance to develop a service-oriented (SOA) front end, so that DSPs could integrate with them – instead of a DMS extraction approach. This turns out to have been the right call, now that Reynolds has shut down DMS extraction. No one I spoke to at the conference has a good solution to the new security measures.
Contact me if you need help developing a sanctioned interface. I have a thorough understanding of the requirements, having been briefed in Dayton by Reynolds developers.