The intake bottleneck
A payment facilitator or acquiring bank receives merchant applications from multiple channels. Some come through a direct web portal. Others arrive via ISO (Independent Sales Organization) partners, each with their own application platform. Others come through integrated software vendors who embed payments into their SaaS products.
Each channel sends merchant data differently. The direct portal captures fields defined by the institution’s own form. ISO partners submit data exported from their CRM systems, with field names and structures that reflect those systems’ data models. Software vendors send API payloads shaped by their platform’s merchant object, which was designed for their product, not for underwriting.
The result: the same type of information (business legal name, DBA, ownership structure, processing volume estimates, bank account details) arrives in as many formats as there are intake channels. Before underwriting can evaluate a single application, someone has to normalize the data into a structure the underwriting system understands.
For a fintech processing a hundred applications a month, this normalization is a manual task absorbed by the operations team. For one processing thousands, it is a pipeline problem that determines how fast merchants can go live.
Business detail variations across platforms
The structural differences in merchant application data are not just cosmetic naming variations. They reflect fundamentally different approaches to organizing the same information.
Business identification might arrive as a single business_name field from one channel, or as separate legal_name and dba_name fields from another, or as a merchant object with name, trade_name, and doing_business_as sub-fields from a third. The EIN (Employer Identification Number) might be formatted with a hyphen (12-3456789), without (123456789), or as a string with leading text (“EIN: 123456789”). Some channels include state of incorporation. Others do not.
Address handling varies in structure and granularity. One platform sends a single address string. Another breaks it into street, suite, city, state, zip. A third uses separate fields for business address and mailing address, while a fourth combines physical and mailing addresses into a single record with a type indicator. International merchants add country-specific address formats: postal codes before city names, province versus state, multi-line street addresses that do not fit a two-line US format.
Ownership records are where the variation gets most painful. US anti-money laundering regulations require identifying beneficial owners with 25% or more ownership. One platform sends ownership as a flat list of individuals with ownership percentages. Another nests owners inside a principals array with sub-objects for each person’s details. A third separates the control prong (the individual with significant management responsibility) from the ownership prong (those with 25%+ equity) into different sections. A fourth sends a single PDF with ownership information formatted as a table.
Processing volume estimates arrive with different granularity. Annual volume versus monthly volume. Average ticket versus total volume divided by transaction count. Card-present versus card-not-present splits reported as percentages, dollar amounts, or both. Some platforms estimate volume by card brand. Others provide a single aggregate number.
KYC document challenges
Beyond structured application data, merchant onboarding requires verification documents, and these arrive in every format imaginable.
Articles of incorporation as scanned PDFs. Business licenses as photographs. Voided checks as images. Bank statements as password-protected PDFs. Tax returns as multi-page documents where the relevant information is on page three of a twelve-page filing.
The traditional approach is to store these documents and have an analyst manually extract the relevant data points: legal entity name from the articles of incorporation, account number and routing number from the voided check, revenue figures from the tax return. This manual extraction is slow, error-prone, and does not scale.
AI vision extraction changes this by pulling structured data from document images and PDFs. A voided check yields an account number, routing number, and account holder name. A certificate of incorporation yields a legal name, state, date of formation, and entity type. The extracted data feeds into the same normalization pipeline as structured application data, arriving at the same canonical merchant record.
Performance data for underwriting decisions
Underwriting a merchant requires more than application data. It requires understanding the merchant’s processing history, chargeback ratios, and risk profile. This performance data comes from yet another set of sources.
A merchant moving from one processor to another can provide processing statements, usually as PDFs, showing monthly volume, transaction counts, chargeback counts, and refund rates. These statements follow the format of the originating processor, which means each one is structured differently.
Processor A’s statement shows monthly volume and chargeback count with a ratio calculated. Processor B’s statement shows gross and net volume separately with chargebacks listed by reason code. Processor C’s statement is a CSV export from their merchant portal with columns that do not match either A or B.
Normalizing this data into a consistent underwriting input (monthly gross volume, net volume, transaction count, chargeback count, chargeback ratio, refund count, refund ratio) requires format-specific extraction and transformation for each processor’s reporting format.
datathere handles this by accepting processor statements in whatever format they arrive. PDF statements go through AI vision extraction. CSV exports go through standard field mapping. The destination is a unified merchant performance schema that the underwriting system consumes regardless of the originating processor.
Monitoring data consolidation
Merchant onboarding does not end at approval. Ongoing monitoring requires consolidating data from multiple sources: transaction monitoring systems, chargeback alert networks, regulatory watchlists, and the merchant’s own reporting.
Each of these sources reports in its own format. The chargeback alert network sends notifications with their own case identifiers and reason code taxonomy. The transaction monitoring system flags anomalies using its own risk scoring model. Regulatory watchlist updates arrive in structured formats that change with regulatory cycles.
When this data feeds into a merchant risk dashboard, the dashboard either needs to understand every source’s native format (which means rebuilding integrations whenever a source changes) or it consumes pre-normalized data from a mapping layer (which means the dashboard has a single, stable integration).
The mapping layer approach means that adding a new monitoring data source (a new chargeback alert network, an additional fraud detection service, a regulatory reporting feed) does not require changes to the dashboard or the risk engine. It requires defining mappings from the new source to the existing canonical monitoring schema.
What speed-to-live depends on
In merchant acquiring, the time between a merchant submitting an application and going live with payment processing directly affects revenue. Every day a merchant waits is a day of processing volume going to a competitor.
The underwriting decision itself takes time; risk assessment cannot be rushed without increasing exposure. But the time spent normalizing application data before underwriting can even begin is pure waste. It adds no value. It mitigates no risk. It is mechanical data reformatting performed by people who should be evaluating risk.
When application data from all intake channels maps to a unified merchant record through certified mappings, the underwriting queue receives clean, consistent applications regardless of the source channel. An application from an ISO partner and an application from the direct portal arrive in the same structure with the same fields populated. The underwriter evaluates the merchant, not the data format.
datathere’s quality enforcement layer adds a second benefit: applications with missing required fields, invalid formats, or out-of-range values get flagged before they reach the underwriting queue. Instead of an underwriter discovering that the EIN is missing and sending the application back to the sales channel, the system rejects incomplete applications at intake with specific field-level feedback. The sales channel fixes the data and resubmits. The underwriting queue stays clean.
The fintech companies that compress their onboarding timelines do not do it by hiring more underwriters. They do it by eliminating the dead time between application receipt and underwriting review — and that dead time is almost entirely a data normalization problem.