I have just wrapped up design work on a web service to cancel and refund F&I product contracts. Whether a refund is owed to the customer, from an early termination, or to the lender as recovered funds, it is in the provider’s interest to support an efficient automated process. On the lender side, it is also a compliance issue.
This job was rewarding for me because it completes the lifecycle I began automating, ten years ago, with electronic rating. MenuVantage was a leader in rating and originating product contracts, and many providers adopted our model specification.
I then did related work at GMAC Insurance, which was to include claims processing. Sadly, the crash of 2008 ended that project. GMAC also had the bright idea to check for an earlier contract, and apply the refund to the results of the rating call.
The industry has been developing web service support piecemeal. First, there was a need for rating and contracting, supported by companies like MenuVantage. Now, there is financial and regulatory pressure to automate terminations, supported by companies like Express Recoveries.
In hindsight, a savvy provider would have looked at the core processes and developed web service support for the whole lifecycle. It would look something like this:
- Dealer and vehicle information ⇒ Return customized rate structure
- Deal information with chosen rate ⇒ Originate contract
- Form request ⇒ Return contract as PDF
- Form with digital signature ⇒ Store in secure archive
- Blank form request ⇒ Return blank form
- Void request ⇒ Void contract, if eligible
- Remittance query ⇒ Return remittance log
- Remittance notify ⇒ Post pending payment
- In-force query ⇒ Return contract data
- Claim diagnosis ⇒ Verify coverage
- Claim estimate ⇒ Approve/deny claim
- Claim entry ⇒ Issue payment
- Vehicle data from contract ⇒ Return cancellation quote
- Contract data plus authorization ⇒ Cancel contract, issue refund
You could do one big API to manage the product from cradle to grave, and build provider portals and such on top of it. This would have the usual benefits of decoupling the back-end from the presentation layer, and it would facilitate integration with dealer and lender software.
My latest article is out in F&I Magazine, just in time for the VSCAC conference. Thanks to Greg Arroyo for his fine editing. The original “history and development of e-contracting” was not so pithy. My thesis is that, while Dealer Track succeeded in driving dealers to a totally new process for online credit, this will not happen for F&I products. With today’s technology, product providers do not need to participate in an aggregation portal. Even the providers’ own portals are suboptimal, because they impose process change on the dealer. The article gives additional reasons why providers won’t follow the Dealer Track model.
As I have written here before, the best place to present products is in a system that the dealer is already using. Ideally, this means the DMS, but it could also include a menu or desking system.
Many Provider Exchange Network customers have dealer-access “portal” sites. These sites support electronic rating, contracting, and a variety of other functions. Providers tell us they’re happy with this approach, and what they really want is DMS integration. We end up referring these customers to 3PA and RCI. Along the way, we try to make the case for PEN.
As I wrote recently in P&A Magazine, the purpose of PEN is to transfer data directly between the DMS and the provider’s administrative system, bypassing any intermediate systems. While we do support a menu system, we connect “behind” it, on the provider side.
Farsighted providers, like Safe-Guard, recognize that their portal is just one tool the dealer might use to sell F&I products. Indeed, some providers use a web-service approach to support a portal in parallel with multiple menu systems. Our pitch with PEN is that going direct to the DMS results in a more streamlined process for 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.