MCA compliance is a stack of product structure, state disclosure rules, broker controls, collections conduct, data retention, and capital-provider governance. This expanded draft turns the framework into a practical operating checklist.
MCA compliance is not a single licensing question. It is a stack of operating decisions that starts before the first lead is bought and continues after the last receivable payment is collected. The stronger shop treats every layer as evidence: product design, offer disclosure, broker conduct, underwriting file, servicing log, collections script, and exception approval. Core source map: California DFPI commercial financing disclosure page ; New York DFS commercial finance disclosure regulation announcement ; Virginia sales-based financing disclosure form rule . Operator thesis Build the stack before volume arrives A funder can be legally correct on one layer and still create risk on another. A true-sale contract does not cure sloppy broker promises. A signed disclosure does not cure unauthorized debits. A registered entity does not cure weak reconciliation handling. The operating model has to connect the layers. The six layers to build and audit Layer What has to exist Evidence to retain 1. Entity and authority Legal entity, ownership/control file, authority to transact in relevant states, registered agent, tax setup, bank accounts, insurance, and capitalization plan. Formation documents, control-person records, secretary of state confirmations, annual report calendar, insurance certificates, treasury approvals. 2. Product structure Receivables purchase agreement, purchased percentage logic, reconciliation policy, no absolute repayment promise, default triggers tied to impairment rather than normal business slowdown. Current contract version, legal memo, reconciliation examples, approval log for contract changes, merchant-facing explanation. 3. State disclosure map Rules by merchant location, amount threshold, product type, broker role, timing of specific offer, signature requirement, and payoff/refinance disclosure rules. State matrix, offer-screen logic, signed disclosures, transmission proof, versioned templates, exception queue. 4. Broker and ISO controls Onboarding, compensation disclosure where required, marketing rules, call/script standards, complaint routing, stacking policy, clawback policy. ISO agreement, W-9/KYB, training records, call reviews, broker ID on every deal, complaint log, commission ledger. 5. Servicing and collections ACH authorization, reconciliation handling, payment modification, UCC process, COJ policy, settlement authority, third-party collector oversight. Payment logs, merchant requests, servicing notes, call recordings where lawful, settlement approvals, collector attestations. 6. Governance and monitoring Compliance owner, monthly QA, policy exception review, investor reporting, complaint root-cause review, change-management approval. Board or management minutes, QA samples, issue tracker, policy signoffs, state-change watchlist, audit trail. A practical build order Week 1 to 2, product and counsel: decide what is being purchased, how the remittance adapts to revenue, what happens when sales fall, and what conduct is prohibited. Do not let sales copy get ahead of the legal structure. Week 2 to 4, state map: build a merchant-location matrix for California, New York, Virginia, Utah, Georgia, Florida, Connecticut, and any other target state. For each state, record whether the trigger is provider, broker, sales-based financing, commercial financing, amount threshold, or recipient location. Week 3 to 5, workflow: put disclosure generation into the offer workflow. The control should fire when a specific offer is extended, not after the merchant has already accepted. Week 4 to 6, channel: onboard brokers and ISOs with written compensation rules, prohibited claims, stacking limits, complaint routing, and evidence-retention duties. Ongoing: sample files every month. Pull one funded file, one decline, one payoff, one default, one broker complaint, and one reconciliation request. The file should tell the story without relying on memory. What a good file proves Question an examiner, investor, bank partner, or court may ask File answer Was this treated as a receivables purchase rather than a fixed repayment loan? The agreement, reconciliation mechanics, payment history, and servicing notes show remittances tied to sales and a real pathway to adjustment. Did the merchant receive the right disclosure at the right time? The file shows merchant location, applicable rule, generated disclosure version, timestamped delivery, and signed acceptance before funding. Did the broker create the risk? The file identifies the broker, compensation, scripts/materials used, merchant communications, complaint history, and any exceptions. Was collections conduct controlled? The file shows authorized contact channels, approved notices, servicing attempts, settlement authority, and no off-script threats or unauthorized debits. Common stack failures Disclosure is treated as a document problem. It is really a workflow problem. The system must know when an offer is specific enough to trigger disclosure. Broker controls sit outside the LOS. If broker ID, commission, and complaint history are not in the file, channel risk cannot be monitored. Reconciliation exists only on paper. A clause that merchants cannot use, staff cannot explain, or servicing does not honor will be weak evidence. Collections is separated from product risk. Aggressive remedies can change how the entire transaction is viewed after default. State rules are updated manually with no owner. A matrix without an owner, review cadence, and change log becomes stale fast. Opinion Compliance should be designed like revenue operations The shops that scale cleanly will not be the ones with the longest contracts. They will be the ones whose systems make the compliant action the default action: right form, right timestamp, right broker evidence, right servicing path, and a clear exception trail.