Lender and DMS Export Formats for Applications

The system on the other side is particular about format. SecureWebX exports the application the way that system wants it, so nobody in the finance office retypes thirty fields into a second screen.

An export format is the shape a credit application takes when it leaves SecureWebX for the system that needs it next, and the platform produces the shape that system expects rather than asking the other side to change. That is the one sentence version. The longer version is that every lender, every DMS and every third party a finance office feeds has its own idea of what an application file looks like. One wants the DMS standard. One wants a fixed width text file laid out to a spec written a long time ago. One wants a spreadsheet. One has an API. SecureWebX speaks all of those, and the store picks the one that fits each destination.

It is important to say plainly what this is and is not, because vendors in this space blur it. This is an export: the application leaves SecureWebX as a file or a request in the format and over the transport a specific destination expects, configured for your store. It is not a live two way integration with a named lender or a named DMS, and nobody on our side will describe it that way. What it gives a store is the practical thing: the application arrives on the other side ready to ingest, without a finance manager rekeying it, and with the delivery recorded.

This page is the product side view of the export capability. The online credit application software page covers the application system as a buying question, and the Send to Lender secure share page covers the other way an application reaches a lender, as a code gated share with a lender response portal rather than as a file.

A franchise store's DMS wants every funded deal's application data in STAR XML, dropped on an SFTP folder the DMS vendor set up years ago. The finance manager finishes working an application in SecureWebX, the worksheet is attached, the lender has responded, and the deal is going to fund. She chooses the DMS destination, the export runs against the mapping template our team built for that store, and a STAR XML file lands on the SFTP folder. The console shows the delivery and how it was delivered. The DMS picks the file up on its own schedule, and the accounting office sees the deal without anyone typing a social security number a second time.

The same store sends applications to a secondary lender that has no SFTP and no API but reads a fixed width file attached to an encrypted email. Same application, different destination, different format, different transport, one click. For a third destination, a local credit union with a small staff, the export goes through the secure portal: a link the credit union opens, with an access code, that presents the application for download. If a direct delivery fails, the console says so plainly and keeps the portal link live as a fallback, and the delivery can be retried once the other side's folder or endpoint is back.

None of that changes the finance manager's job. She works the application in one place, and the format and transport questions were answered once when each destination was set up.

Leave your number and a lead specialist calls you back to answer your questions about pricing, coverage, and setup. Mon - Sat, 9:00 AM - 6:00 PM Pacific.

Prefer to talk right now? Call or text 844-376-2274.

STAR XML is the standard most DMS platforms and many franchise systems expect, and it is the format to reach for when the destination is the store's DMS. Fixed width is the older text layout still used by lenders and processors whose intake systems were built to a column spec; every field starts at a known position and is padded to a known length, which is exactly why a hand typed file breaks and a generated one does not. CSV is the spreadsheet friendly option for destinations that import a table, and for a store that wants a copy of its own applications in a form it can open. JSON is the format an API expects, and it is the shape a modern lender platform or a custom integration reads.

The format is chosen per destination, not per application. A store that sends the same application to its DMS and to a lender sends STAR XML to one and a fixed width file to the other, from the same record, without editing anything. Where a destination has a layout of its own, a mapping template captures it, which is the subject of a later section.

Format is what the file looks like. Transport is how it gets there, and the two are chosen independently. SFTP drops the file on a secure folder the destination polls, the way most DMS vendors work. SOAP and a REST API send the application as a request to a destination that exposes an endpoint, which is how lender platforms and custom systems receive it. PGP encrypted email sends the file as an attachment encrypted to the destination's key, for lenders who work from an inbox but insist, correctly, that the attachment be unreadable to anyone else. Structured email is a plain email laid out in a fixed structure for destinations that parse their inbox. The secure portal presents the application at a link with an access code, for a destination that has none of the above and should not be handed a raw attachment.

Any transport can be paired with any format, within reason, so a store's DMS might take STAR XML over SFTP while its special finance lender takes JSON over a REST API and its warranty partner takes CSV through the portal. Each pairing is a destination in the console, set once. For the lenders who still work by fax, the eFax capability sits alongside these.

The reason exports fail in most systems is not the format, it is the fields. Your application calls something monthly housing payment; the lender's spec calls it rent or mortgage amount and wants it in whole dollars in a column of its own. A mapping template records that translation, field by field, for one destination. Once it exists, every application exported to that destination follows it, and a change on the other side, a new required field or a renamed one, is a change to the template rather than a retraining of the finance office.

Templates are built per destination by our team with the destination's spec in hand, and a store that adds a lender adds a template. Because the application in SecureWebX already carries the personal, residence, employment, income, co-applicant, trade and down payment sections in structured fields, and the attached worksheet carries the deal structure, most templates map cleanly from what is already there rather than asking the finance manager to fill in extra fields at export time.

Export lives in the SecureWebX console, which opens from the SecureWebX button on the LeadLocate CRM dock with one login, and in the SecureWebX app on iOS and Android. Each application carries its delivery controls: choose the destination, see how it was delivered, retry if a direct delivery failed, open the portal link. Destinations and their mapping templates are configured for the store rather than by each user, so the finance manager sees a short list of places an application can go and picks one.

What it replaces is rekeying, and the cost of rekeying is easy to underestimate. A finance manager who types an application into the DMS and again into a lender's portal spends real time per deal and introduces a transposed digit somewhere in a social security number or an income figure often enough that funding gets delayed. It also replaces the per integration fee that some application vendors charge for each lender or DMS connection. SecureWebX is part of every LeadLocate plan rather than an add on, plans are month to month, and the pricing page lists them.

An application leaving the building is the moment a store's control over the data is weakest, so the transports are built for it. SFTP is an encrypted transfer. PGP email encrypts the attachment to the recipient's key so a misdirected or intercepted message is unreadable. The secure portal gates access behind a code and presents a watermarked view. Every export is written to the audit log, so a question about where a customer's application was sent has a documented answer.

Retention follows the SecureWebX rule: archive, never delete. The application, the worksheet, the delivery record and the lender's response stay together on a record that is retained for compliance. The credit application security page covers the controls around the record in detail. As with everything in this family, the software gives the store's compliance program a record to stand on; it does not stand in for the program.

Export destinations are set up per store by our team, because each one needs the receiving system's spec, credentials and transport details. Tell us where applications need to go, your DMS, your lenders, a processor, and share the spec or the contact who has it. We build the mapping template, connect the transport, run a test file, and the destination appears in your console. Adding a lender later is the same conversation. A destination with a format or transport not on this page is available on request, and our team puts it in production for your dealership; the partner integrations catalog in the console also carries a custom integration request for exactly that.

Pair export with Send to Lender, so lenders who want a reviewable share get one and systems that want a file get one, and with the Verified Partners directory, where the partner integrations catalog lives. The all features list shows where export sits among everything else in the platform, and the pre-recorded live demo shows an application going from a text message to a worked, lender ready file.

Is this a live integration with my DMS or my lender?

It is an export in the format and over the transport your DMS or lender expects, configured per destination with a mapping template. The application leaves SecureWebX as a file or a request the other side ingests. It is not a live two way connection with a named system, and we describe it as an export on purpose.

Which formats are supported?

STAR XML, the DMS standard, plus fixed width, CSV and JSON. The format is chosen per destination, so the same application can go to a DMS as STAR XML and to a lender as a fixed width file.

How is the file delivered?

Over SFTP, SOAP, a REST API, PGP encrypted email, structured email or a secure portal with an access code. Any transport can be paired with any format, and each pairing is a destination set up once for your store.

What if the lender's layout is different from ours?

A mapping template records the field by field translation for that destination. Our team builds it from the destination's spec, tests it, and every export to that destination follows it from then on.

What happens if a delivery fails?

The console says so, keeps the secure portal link live so the destination can still retrieve the application, and lets you retry the direct delivery once the other side's folder or endpoint is available.

Is export an extra charge?

No. Export formats and transports are part of SecureWebX, which is part of every LeadLocate plan. Plans are month to month and listed on the pricing page.

STAR XML, fixed width, CSV or JSON, over the transport your lender or DMS already uses. Part of SecureWebX, part of every LeadLocate plan, month to month.

Prefer to talk right now? Call or text 844-376-2274.