Where should lender matching sit inside an ISO workflow?
The matching API can be called after deal facts are normalized and before documents are routed. The response should remain advisory: show passed, failed, and unresolved checks, preserve the source timestamp, and require a human to confirm current criteria before submission. How are you separating automated routing from final placement approval?
10 replies
Our clean sequence would be intake, fact normalization, matching, explanation of each check, and then human confirmation before routing. The matcher should return passed, failed, and unresolved fields rather than a single unexplained score.
I want the same workflow to search either every eligible lender or only an ISO user’s favorites. Favorites are a working shortlist, but the all-lenders view helps us avoid missing a fit.
Unknown criteria should produce “review,” not an automatic decline and not an automatic approval. Missing information is different from a failed threshold, and the interface should make that distinction obvious.
The source date is useful context, but older confirmed criteria should not remove a lender. Final placement approval remains with the ISO and lender after the current file and any unresolved criteria are checked.
Should the API return lenders with unresolved fields, or only fully confirmed matches?
Return them in a review group with the unresolved checks listed. Omitting them would confuse missing data with ineligibility.
That is especially important when a lender has valid criteria for credit and revenue but has not published an industry rule.
The human reviewer can then verify the unknown field before submission while preserving the automated reasons already evaluated.
Favorites should be a scope option, not a different matching method. The same evidence and explanations must apply to both scopes.
A shareable result should also show that it is a routing aid, not a lender approval or merchant offer.