A guide for MCA funders
The 3-phase migration plan
Configure, run parallel, then cut over. In that order.
MCA migration has one non-negotiable rule: you do not cut over cold. You don't shut down your spreadsheets on a Friday and run everything on the new platform on Monday. If anything is misconfigured — a payment schedule, a balance, an ACH reference — you won't find out until it's live and a merchant gets the wrong debit or an ISO gets an incorrect offer.
PHASE 1
Configure and load
Weeks 1-3
- User roles and permissions configured — underwriters, ops, collectors, finance, and executives each have the right access level
- Deal stages defined and locked, covering your standard statuses from New Submission to Paid Off.
- Underwriting scorecard configured with your FICO thresholds, revenue minimums, time-in-business requirements, and position stacking rules
- Decline reasons, approval conditions, and exception logic documented and entered.
- ACH processors connected — Onyx IQ integrates natively with ACHWorks, Actum, ACH.com, UZO, and Wells Fargo.
- Commission structures configured for active ISOs.
- Syndicator profiles set up with correct participation percentages.
- Historical closed deals imported as reference records, not as active portfolio.
- Onboarding timeline confirmed with your vendor — most MCA platforms target 2–4 weeks to go-live.
PHASE 2
Parallel run
Weeks 3-5
What to compare daily
| What to compare daily | Why it matters |
|---|---|
| New deal status in platform vs. spreadsheet | Confirms workflow routing is correct. |
| Payment schedule outputs vs. ACH processor | Catches misconfigured payment amounts or frequencies before first debit |
| Active deal balances vs. spreadsheet source of truth | Identifies any import discrepancies before they compound |
| Collections queue vs. manual tracking | Confirms failed payment triggers and escalation logic are firing correctly |
| Syndicator allocations vs. investor spreadsheet | Catches any rounding or percentage errors before a statement goes out |
| Commission calculations vs. ISO tracker | Confirms payout logic matches agreed structures |
Run the parallel period for at least one full reporting cycle — typically two weeks minimum for an MCA shop with daily ACH activity. Do not move to Phase 3 until every item above passes clean.
PHASE 3
Cutover and lock
Weeks 5-6
Once parallel validation is clean, you cut over. Spreadsheets become read-only archives: saved, accessible for reference, and frozen.
- All new submissions are entering the platform with no new entries in pipeline spreadsheets.
- Active payment schedules are live in the platform and syncing with ACH processors.
- Active deal balances in the platform match the last parallel validation.
- Collections queues are active and failed payment workflows are triggering correctly.
- All users have been trained on their role-specific workflows.
- Old spreadsheets saved as read-only archives with a clear naming convention.
- Cutover date announced to the entire team — everyone knows which system is now authoritative.
- A dedicated support contact at your platform vendor established for the first 30 days post-go-live.
On the ACH handoff specifically.
This is the highest-risk moment in the entire migration. A misconfigured ACH schedule means a merchant gets double-debited or misses a payment. Before you activate payment processing through your new platform, reconcile every active payment schedule to the penny against your ACH processor. Run a dry sync. Confirm the batch file matches expected daily collection amounts. Then activate. Do not do this during a high-volume week.