Month: October 2016

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.

Three Requirements for Online Car Buying

In this post, I am going to elaborate on Dealer Systems in the Consumer Space.  Every system in F&I must have a counterpart in the consumer space.  The diagram below shows the traditional dealer process in orange, and consumer systems in blue.

online-retail

Each of the six tasks is now, or will be, available to customers online.  Obviously, these are web based systems and, for best results, they are also mobile.  Each consumer system must:

  • Share data with its dealer-system counterpart
  • Share data with other consumer systems
  • Save deal data for later use

Each consumer system must share data with its dealer-system counterpart.  If it quotes a VSC rate, the customer will expect to see that rate on the menu in the dealership.  If it obtains a credit decision, the customer will expect the dealer to know about it.  There are various ways to accomplish this.  In the VSC example, both systems should be reading rates from the same API.

Consumer systems must also share data among themselves.  Vehicle data is input to VSC rating, price is input to deal structuring, and the “line five” subtotal is input to credit processing.  It’s a good idea to keep a data-flow diagram handy.

Finally, the consumer systems must cooperate to store in-process deal data.  Customers should be able to choose which tasks they wish to do online, and then save the deal to be completed at the dealership.

I am mainly addressing new entrants from outside the industry, who may have a good system for one of the tasks, but fail to connect with the others.  This may also include dealer groups moving into online car buying, and system vendors like Cox.  My chart of platform capabilities is here.