Credit applications and lenders
Getting a credit application to a bank without a RouteOne seat
A small independent store with no RouteOne or Dealertrack seat can still run the finance side properly. The customer completes and signs their own credit application from their phone, with the Social Security number encrypted before it is stored. The car is booked out on a sheet that names the book and the date the figure came from. Each lender in your directory gets the application in the shape that lender actually takes it — an email package with the application and book-out sheet attached, or the same fields in the order of the platform screen your manager already logs into. Decisions record back onto the deal, so which bank bought it, at what rate, with what stips, is a query rather than a phone call. The Dealertrack credit-application rail is built against the Dealertrack API and is in certification with Cox; it is not carrying real applications yet.
What this is, and what it is not
This is not a credit network and we will not call it one. Nothing here sends an application to a bank by itself today. The Dealertrack credit-application rail is built against the Dealertrack API and is in certification with Cox, production runs against the sandbox, and no live submission has ever completed — so no lender has yet seen an application sent from this system.
What this is: everything up to and around that last step, done once and done properly. A real credit application the customer fills in and signs themselves, with the identifiers encrypted and every read of them logged. A directory that knows how each of your banks takes an application. A packet built for that bank specifically. A book-out sheet honest about where its number came from. And one place where every lender’s answer is recorded against the deal, whether it arrived by itself or a manager typed it in off a portal.
The application
The part a store gets wrong most often is not the sending. It is having a complete, signed, legible application in the first place — with an income the customer stated rather than one a salesperson guessed.
The customer fills it in, not your desk
Send a link and they complete the application on their own phone, at home, without an account or a login. They type their own Social Security number, date of birth and licence number, and sign by typing their full name after ticking the credit-inquiry authorization and an E-SIGN consent. Both boxes are required to submit; neither is pre-ticked.
Encrypted before it is stored
Social Security number, date of birth and licence number are encrypted before they reach the database, hidden from every list and screen, and decrypted only where a document or a submission genuinely needs them — each of those reads writing an access-log row naming the person, the reason and the deal. Gross monthly income, other income, the housing payment and any credit score a lender returns are encrypted at rest the same way.
Individual, business, and a co-applicant
A business application asks for the entity, its type and its time in business, and takes the owner or officer as the personal signer, because that is whose credit the bank checks. A co-applicant carries their own encrypted identifiers and their relationship to the applicant. If the customer would rather sign on paper, printing the application leaves the SSN and licence boxes blank to be filled in by hand.
The lender directory
Independent stores do not deal with one bank, and no two of them take an application the same way. The directory is where that knowledge stops living in one manager’s head.
Your banks, not a marketplace
One row per lender you actually deal with: contact name, intake email, phone, the dealer number that lender issued your store, the valuation book they advance against, and the stipulations they always ask for. It is separate from your rate sheet on purpose — you learn a bank’s phone number long before you negotiate its buy rates.
How each lender takes an application
Every lender carries a channel: email for a bank on no platform, platform for one that only takes applications through an aggregator you already log into, the lender’s own portal, or the Dealertrack API. Emailing a platform-only bank is slower than the platform, not faster, so the channel decides what gets built rather than a default.
It refuses rather than guesses
A lender whose channel nobody has established will not fall back to email. A bank on the email channel with no address on file, or on the platform channel with no platform recorded, is refused by name with the field a manager can go and fill in. An unestablished route is not a degraded route; for some banks it is the wrong one.
Try Lead Friendly free for 7 days
AI voice agents + CRM + TCPA-gated compliance. 30 minutes included. No card required.
What you carry to the bank
Four artefacts, built from the deal rather than re-keyed, and each one shaped by the channel the lender is actually on.
An email package for a bank on no platform
Recipient, subject and body already written, with the credit application PDF and the book-out sheet attached. Nothing is sent from here: it is a draft a person reads and sends from their own mail. The email itself carries no identifiers — the Social Security number travels inside the attached application, which is rendered by its own audited route.
A paste set for a platform-only lender
The same application laid out in the order a credit-application screen asks for it: identity, current address, previous address, employment, income, co-applicant, then the vehicle and the money. Sensitive fields stay masked until revealed. This does not bypass the platform — the lender gets the decision speed they get today, and what goes away is your ten minutes of retyping.
The book-out sheet
The vehicle, its equipment, the figure, and where the figure came from: the book, the value type, and the as-of date printed beside the number rather than in a footnote. Ask for it addressed to a particular lender and it says who it was prepared for, and flags on the page when that lender advances against a different book than the one your store keyed in.
A STAR credit application export
The application as a STAR ProcessCreditApplication BOD, the standard the credit aggregators speak underneath. Nothing consumes it today and we do not pretend otherwise. It exists so that when a lender’s technical team asks what you can send them, the answer is a standard document rather than JSON somebody invented, and it is gated exactly like the packet because it carries an unmasked taxpayer identifier.
Everything that carries the application is gated the same way: the desk entitlement, then the permission to run credit, then whether the lender can be reached at all, then the customer’s third-party disclosure attestation. Only after all four is anything decrypted, and the read is logged before the bytes are handed over. The book-out sheet is deliberately not gated that way, because there is no person on it — only a car, a number, and the name of the book the number was read out of.
When the answer comes back
One application, several banks, one place for the answers
A deal shopped to four lenders is four rows, each with its own status, approved amount, buy rate, term and stipulations. Whether the answer arrived over a callback or a manager read it off a portal and typed it, it lands in the same shape — so which lender bought a deal, at what rate, with what stips is a query instead of a phone call.
Statuses spelled the way a bank spells them
Submitted, pending, approved, conditionally approved, declined, funded. Pending is a real state and means the bank has it and has said not yet, which is a different thing from never having been asked. Funded means the money arrived and this was the lender you took, which is the number that tells you where to send the next deal.
What a rep sees, and what they do not
Buy rate is what the lender charges the store and sell rate is what the customer pays; the spread between them is reserve. The comparison hides the buy rate and the spread from anyone without the permission to see them, and the fair-lending report on the parent page flags a deal where markup ran past your cap.
Against the structure you desked
An approval is compared with the deal as desked: what the bank will advance against what you asked them for, and how far short it falls when it falls short. An approval that will not carry the structure shows up on the comparison rather than as a surprise at funding.
The Dealertrack rail, and exactly where it stands
There is a credit-application rail built against the Dealertrack API, under a Cox partner account, and it is in certification with Cox. The mapping is generated from the published API document, so a field renamed upstream is a build failure rather than a rejection on somebody’s deal. Every request and response is recorded with the identifiers redacted. A submission cannot be fired by a cron, a retry or a stale client: it needs an explicit confirmation from a person, a lender deliberately placed on that channel, a dealer number on file, and Cox’s own id for that bank. Sending the same application to the same bank twice is refused, because that is a second hard inquiry on a customer’s credit report.
And it is not carrying real applications. Production runs against the sandbox, no live submission has ever completed, and no lender has received an application through it. The gates, the persistence and the refusal paths are exercised by tests; the send itself is documented rather than proven, and the first real submission will be watched by a person. We will change this paragraph when that happens, and not before.
What it does not do
Better to read this now than to discover it on a deal:
- The Dealertrack credit-application rail is not carrying real applications. It is built against the Dealertrack API and is in certification with Cox. Production runs against the sandbox, no live submission has ever completed, and no lender has ever received an application sent from this system. Until that changes, a deal reaches a bank because a person emailed the packet or typed the paste set into the platform.
- It does not pull credit. There is no bureau connection, no score fetched here, and no decision made here. You record what the bank came back with — and because nothing is pulled, nothing on this page can put an inquiry on a customer’s file by itself.
- It does not pull live book values. The Kelley Blue Book connection is sandbox-only under an agreement that is not signed, and the sandbox’s own figures are roughly six months stale — production access is refused outright in code rather than left to an environment variable. Every number on a book-out sheet was keyed in by a person reading the book their own store subscribes to, and the sheet says so on its face. No book’s name is ever used as a letterhead.
- There is no RouteOne API connection, and none to CUDL or DealerCenter either. For a lender who only takes applications through a platform, what this removes is your retyping, not the platform. A person still opens that screen and puts the application in.
- Nothing here sends anything on its own. No queue, no retry, no cron, no background job. The email is a draft somebody reads before sending, the paste set is fields somebody types, and every API path requires an explicit confirmation from a person who clicked. A resend of a credit application is a second hard inquiry on somebody’s credit report, so it is not a thing software should do quietly.
- The STAR export has no consumer. No lender is ingesting it, and its envelope is standard OAGIS while the element names inside have not been checked against a licensed STAR schema. Anyone about to send it to a real bank has to diff it against the schema that bank hands them first.
Frequently asked
Can I submit a credit application to a lender without RouteOne?
You can take the whole application and get it to the bank, but be clear about who carries the last step. The customer completes and signs the application themselves, the SSN is encrypted at rest, the car is booked out on a sheet that names the book and the date, and the system produces either an email package with the application and book-out sheet attached, or the same fields in the order of the platform screen so a manager tabs down it instead of retyping. A person sends the email or types the paste set. What this replaces is about ten minutes of retyping per deal and the guesswork about how each bank wants it; what it does not replace is the platform seat itself.
Is this a Dealertrack alternative?
For an independent store that never had Dealertrack or RouteOne, it is a way to run the finance side without one: a real credit application, a lender directory, a packet per bank, a book-out sheet, and the decisions recorded in one place. It is not a replacement for the credit network itself. Dealertrack and RouteOne are how banks receive applications, and that network is thirty years old. We have built a credit-application rail against the Dealertrack API and it is in certification with Cox — it is not carrying real applications yet, so nothing on this page should be read as us having replaced that pipe.
Has a lender actually received an application sent from this system?
No. The Dealertrack rail is built against the Dealertrack API and in certification with Cox; production runs against the sandbox and no live submission has ever completed. Every deal that has reached a bank from here reached it because a person emailed the packet or typed the fields into the platform. We would rather write that sentence than have you discover it in month two.
Does the customer type their own Social Security number?
Yes, and that is the point. The application link opens without a login, the customer fills it in from their own phone, and they enter their own SSN, date of birth and licence number. Those fields are encrypted before they are stored, hidden from every list and screen, and decrypted only for the printed application, the paste set, the STAR export or a submission — each of which writes an access-log row naming who read them and why. If the customer would rather do it on paper, the printed application leaves those boxes blank to be filled in by hand.
What is in the submission packet?
It depends on the lender, which is the whole reason the directory carries a channel. For a bank on no platform you get a ready-to-send email — recipient, subject, body — with the credit application PDF and the book-out sheet attached, which you read and send yourself. For a bank that only takes applications through an aggregator you already log into, you get the same application as an ordered set of fields matching the sequence that screen asks for, with SSN, date of birth and licence masked until revealed. For a lender whose channel nobody has established, you get a refusal naming what is missing rather than a guess.
Where does the number on the book-out sheet come from?
From a person at your store, reading the book your store subscribes to. This platform does not licence a valuation book: the Kelley Blue Book connection is sandbox-only under an unsigned agreement with figures about six months stale, so nothing it returns is fit to send a lender. The sheet is designed around that fact — the source and the as-of date are printed beside the figure, the value type says not specified when nobody recorded it, the sheet states plainly that the dealership entered the number, and no book appears as a letterhead. A lender advances real money against that page, so it must not look like something it is not.
How does a lender decision get onto the deal?
Two ways, producing the same rows. A manager reads their portal and records the answer — status, approved amount, buy rate, term, stipulations — against that lender on that deal. Or, on the Dealertrack rail, a decision arrives on a callback and is written down automatically: every event is stored with its own id, redelivered and out-of-order events are recognised as such so a late pending cannot take a live approval off the screen, and a person can also ask the bank directly rather than waiting. That second path is in certification and is not carrying real decisions yet.
Why does the lender directory record a dealer number per bank?
Because every bank issues its own. It is not your state licence and not a DMS id, and it is what a submission routes on — which is why it sits on the lender row rather than on the store. A submission that cannot be attributed to a dealer is a rejected application at best, so a lender on the API channel with no dealer number on file is refused by name instead of being sent anyway.
Do I need the rest of the desking software to use this?
Yes, in practice. The application, the packet and the book-out sheet are all built from the deal — the structure, the vehicle, the trade, the amount financed — so they come from the same engine that desks the deal and prints the contract. There is no standalone credit-application product, and there is no data pipe into DealerCenter or Frazer, so running this alongside a DMS means the deal is entered here.
Keep reading
Try Lead Friendly free for 7 days
AI voice agents + CRM + TCPA-gated compliance. 30 minutes included. No card required.