Category: Service Oriented Architecture

Caching the Rate Response

Every so often, I am asked to write on a specialist topic for F&I technology, like surcharge processing, term bumps, or credit life math.  Today’s topic is well known in dealer system software, but bears repeating for the new generation of digital retailers.  This is the problem of how long it takes to receive rates for protection products from the provider’s web service, also known as “latency.”

The good news is that all providers today expose their rates via web service, so they’re always up to date and tailored to the current deal.  It wasn’t always thus.  We once had to scan reams of paper rate guides, and walk ten miles in the snow.  The bad news is that the web rating call can take several seconds to run.

A savvy rate response already has Squish VIN in it, so you just smack the whole thing into Mongo and you’re good to go. 

In the typical scenario, a menu system calls the provider’s web service directly, passing the VIN and the dealer number.  The dealer number is required because product pricing and selection may vary with the dealer.  This may not be the case for digital retail.  You may have a standardized slate of products (or just one product) with a mandatory fixed retail price, and not care about dealer-specific costs and packs.

You still have to pass the VIN, in any case, because most products are risk-rated by model.  Then you wait.  At MenuVantage, we set the timeout for twenty seconds.  If a provider couldn’t respond within twenty seconds, they couldn’t be on the menu.  Digital retail, of course, requires a much faster response.

The rate response for an old-school SOAP call, returning all products for a single model, is about 500 KB, or 10,000 lines of XML.  I have seen them exceed one megabyte (you know who you are).  A well-done web service can transmit the rate response in about one second, and then another second or so for the integration hub.

Most menu systems do not interface directly with the provider.  They go through a central hub like PEN or F&I Express.  These are the main ones (full disclosure: both are clients) but there are others, and a slow rate hub can add seconds of latency.  Digital retail is more likely to be using REST and requesting a specific product.  The biggest product is a service contract, weighing in around 2,000 lines of JSON or 100 KB.

Ideally, all networks and services would be fast, and you would always send the request.  “The network is the computer.”  On the other hand, maybe you ought to cache the rate response.  To do this, simply save each response in a database, keyed by dealer number and Squish VIN.

If you’re in the “don’t care about dealer” scenario described above, then omit the dealer number.  If you expect to rate specific products, as opposed to the menu scenario, then take apart the response according to its (provider-specific) product segmentation.  A savvy rate response already has Squish VIN in it, so you just smack the whole thing into Mongo and you’re good to go.

The point to Squish VIN is that, of the 17 characters, only ten really matter.  The first eight identify the model and trim, and the tenth position encodes the model year.  This is what the provider uses to risk-rate by VIN.

Common practice for digital retail is to pull an inventory list and rate every vehicle on the lot.  That’s some redundant rate requests.  A dealer might have 500 cars on the lot, but only seventy unique VIN patterns.  Even if you’re compulsive about stale cache, and you want to rate every night, this is still a sevenfold improvement.

So, the procedure is: every time you want to rate, either in batch or on demand, go first to the cache.  If there is no matching Squish VIN in the cache, only then must you take the hit for a live rate request.

Menu systems generally do not do the lot-scan thing.  This seems to be new with digital retail.  Generally, we would just expire the cache at midnight and start rebuilding with the next day’s deals.  The first Cherokee takes a hit, and then the first Wrangler, and after that you’re rating Cherokees and Wranglers all day long from cache.

Also new with digital retail are various use cases that don’t require a dealer number.  This vastly improves the efficiency of the cache.  Instead of seventy VIN patterns per dealer, you might have seventy for the whole country.

Full Lifecycle API for F&I Products

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.

product-lifecycle

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:

  1. Dealer and vehicle information  Return customized rate structure
  2. Deal information with chosen rate  Originate contract
  3. Form request Return contract as PDF
  4. Form with digital signature Store in secure archive
  5. Blank form request  Return blank form
  6. Void request Void contract, if eligible
  7. Remittance query Return remittance log
  8. Remittance notify ⇒ Post pending payment
  9. In-force query Return contract data
  10. Claim diagnosis Verify coverage
  11. Claim estimate Approve/deny claim
  12. Claim entry Issue payment
  13. Vehicle data from contract Return cancellation quote
  14. 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.

Business Process Modeling

51XB28IfytL._SX331_BO1,204,203,200_I am doing a Business Process Reengineering (BPR) project for LoJack Corporation.  It is to their credit that a mature organization like LoJack is willing to examine its business processes.  This is part of a broader effort to increase F&I penetration, and it promises to be a lot of fun.  Readers of this blog know how much I enjoy BPR, and Dr. Hammer.

After much deliberation, we chose Business Process Modeling Notation (BPMN) for the project.  My main concern was having diagrams that would be easily understood by everyone on the team.  Not everyone who is an expert in F&I is also an expert in BPR.  I also wanted notation that would keep track of data flows, and was well supported by textbooks and software tools.

If we had only IT people on the project, I might have recommended UML or ODBA, but both of these are too technical.  Also, UML doesn’t do a great job of combining process and data flows.  I think the absolute best notation on this point is Event Process Chain (EPC) but it, too, requires special training.  There is a great paper out of Harburg Tech, by the way, comparing UML and EPC.  The windup is that UML is better for software and EPC is better for process.

As to support, BPMN is an Object Management Group (OMG) standard.  Visio 2010 not only supports BPMN, but it includes a syntax checker.  This will be important for people new to the tool and the notation.  I also found a number of good recent textbooks, including The Micro Guide to Process Modeling.  This is a concise “how to” that will serve us well, and it includes some good style tips.  Happy modeling!

Web Services for F&I

I have just returned from the annual F&I conference.  It was a treat to see all my old friends in the industry.   I participated in a panel discussion on web services, an area where I have some experience.  Click here for my white paper.

The discussion was well attended, even at five o’clock with the open bar beckoning.  Not bad for a technical topic.  The panel was cordial, even though we are mostly competitors.  There was some debate over my assertion that web services can reduce IT costs.

From the audience questions, I detected genuine interest – and I believe we gave some useful answers.  Thanks to Brian, Brent and Kumar.  Let’s meet again next year!