MCA Compliance by Design: The Data Fields Every Funder Should Track
MCA compliance should be built into data fields, not managed through memory. This expanded guide lists the fields funders should track across intake, offer, disclosure, broker, underwriting, servicing, collections, complaints, and audits.
MCA compliance should not depend on a senior operator remembering what happened. The file should prove it. That means compliance has to be embedded in data fields across intake, offer generation, disclosure, broker management, underwriting, servicing, collections, complaints, and portfolio reporting. Operator thesis If the field does not exist, the control probably does not exist Policies sound strong until an auditor asks for evidence by merchant, state, broker, offer version, disclosure timestamp, reconciliation request, or collector action. Data design is compliance design. Core intake and identity fields Field group Fields to capture Why it matters Merchant identity legal_name, dba, EIN, formation_state, business_address, principal_business_state, owner_names, ownership_pct, website, phone, email. Supports KYB, state rules, contract parties, UCC, and communication records. Channel broker_id, broker_user_id, lead_source, affiliate_source, referral_source, consent_record, marketing_campaign. Supports broker oversight, lead-source risk, complaint tracing, and commission controls. Product request requested_amount, use_of_funds, current_positions, payoff_requested, renewal_flag, state_rule_candidate. Supports suitability, stacking review, disclosure triggers, and renewal controls. Offer and disclosure fields Field group Fields to capture Control enabled Offer economics funding_amount, purchased_amount, factor_rate, purchased_percentage, expected_payment, frequency, estimated_term, fees, broker_compensation. Calculates disclosures, pricing review, APR/annualized metrics where required, and portfolio economics. Disclosure trigger recipient_state, product_type, threshold_rule, disclosure_required, disclosure_template_id, calculation_version. Ensures the correct state and product template fires before acceptance. Delivery proof disclosure_generated_at, delivered_at, delivered_by, delivery_channel, signed_at, signature_method, broker_transmission_proof_url. Proves timing and merchant acceptance. Exception exception_type, approver, approval_reason, expiration, remediation_required. Prevents undocumented overrides from becoming the real process. Underwriting and risk fields Cash flow: monthly deposits, average daily balance, negative days, NSF count, overdraft count, returned items, deposit concentration, processor volume, seasonality notes. Obligations: existing MCA positions, daily debits, payoff amounts, tax liens, UCCs, judgments, rent arrears, payroll/tax obligations, chargebacks. Fraud and KYB: identity checks, business verification, bank account ownership, document authenticity flags, phone/email domain checks, sanctions/adverse media where appropriate. Decisioning: policy version, underwriter, score, decline reason, stipulations, exceptions, compensating factors, approval authority, funding cap. Broker and ISO oversight fields Field Purpose broker_status Active, probation, suspended, terminated. broker_registration_state_flags State-specific broker obligations and evidence. broker_training_completed_at Proof that the ISO received product, disclosure, and prohibited-claims training. broker_commission_amount Compensation transparency, disclosure support, chargeback control. broker_file_quality_score Missing docs, late disclosures, corrections, and compliance exceptions. broker_complaint_count Early warning for conduct risk. broker_loss_rate Performance risk and potential mis-selling signal. Servicing, reconciliation, and collections fields Workflow Required fields Daily servicing payment_due, payment_received, return_code, balance_collected, purchased_amount_remaining, payment_method, account_status. Reconciliation request_at, request_reason, supporting_docs, reviewer, decision, adjusted_payment, effective_date, merchant_notice_at. ACH disputes return_code, unauthorized_claim, authorization_status, stop_debit_at, review_owner, resolution. Collections breach_type, evidence_packet_url, approved_remedy, approval_owner, demand_sent_at, legal_referral_at, settlement_authority. Releases payoff_at, UCC_release_due_at, UCC_release_at, COJ_release_at, settlement_closed_at. Data model rules that prevent chaos Version everything: contract templates, disclosure templates, pricing models, underwriting policies, state matrices, and broker agreements. Never overwrite key evidence: append new disclosures, decisions, and payment changes. Preserve originals. Use controlled vocabularies: decline reasons, exceptions, complaints, return codes, breach types, and collection remedies should not be free text only. Link records: deal, merchant, broker, offer, disclosure, image/document, ACH event, reconciliation, complaint, and collection action should connect to one file. Build audit exports: state, broker, date range, product type, status, disclosure required, disclosure missing, complaint flag, and collection remedy. Minimum dashboard for management Dashboard tile Why it matters Deals funded without required disclosure evidence Hard control failure. Broker exceptions and complaints by month Channel risk signal. Reconciliation requests approved, denied, pending True-sale and servicing evidence. Unauthorized debit claims and ACH return reasons Payments and collections risk. State exposure by funding amount and open balance Regulatory concentration. Early-default rate by broker, state, industry, and underwriter Fraud, underwriting, or sales-conduct signal. Opinion Compliance tooling should answer questions instantly A strong MCA system should be able to answer: who sold this, what state rule applied, what was disclosed, what changed after funding, what the merchant requested, what collections did, and who approved each exception. If it cannot, the compliance program is still too manual.