For acquirers, PSPs and PayFacs building product. A proposed agent that frames merchant onboarding, the PayFac model, SoftPOS and interchange++ pricing — grounded in the acquiring and compliance tree. It structures the product question; underwriting, pricing and risk decisions stay with humans.
This agent is part of a proposed roster of four role agents for payments executives and consulting teams. It is scoped here so partners can pressure-test the brief before any of it is built. The one agent that is live today is the research & regulatory-watch agent — the editorial engine that keeps the knowledge base these role agents would read from current and human-moderated.
Building acquiring product means living in a tangle of merchant onboarding, the PayFac model, SoftPOS certification and interchange++ pricing — all of it bounded by scheme rules and PCI scope. The questions are structural and they recur with every new merchant segment.
The acquiring / PSP product agent is a proposed agent that frames those structural questions. It reasons over the acquiring and compliance leaves to lay out onboarding flows, the sub-merchant economics of a PayFac, what SoftPOS adds and where interchange++ pass-through lands. It drafts the product and pricing structure — underwriting a specific merchant, setting a real price and owning the risk stay with the acquirer’s humans.
The agent is a thin reasoning layer over a thick, moderated knowledge base. It does not free-associate; it retrieves expert-approved leaves, reasons over them, cites the source, and hands a draft to a human.
// Acquiring product agent — structure, not underwriting 1. ASK “Onboard this segment as PayFac sub-merchants or as direct MIDs, and what does SoftPOS change?” 2. RETRIEVE pull modes/acquiring-softpos + compliance/, scheme PayFac rules, PCI scope for the flow 3. FRAME onboarding flow, risk-tier structure, pricing shape (interchange++ vs blended), certification load 4. FLAG mark the human decisions: underwriting, KYC depth, risk appetite, the actual price 5. HAND OFF the product / risk owner decides. The agent never approves a merchant or sets a live rate.
Designing merchant onboarding, risk tiers and the product wrapper around card and account acquiring.
Working out sub-merchant onboarding, the aggregation model and where scheme and PCI obligations land.
Framing interchange++ vs blended pricing structures before the numbers go to a real quote.
Onboarding flow, KYC/KYB depth by risk tier and the documentation gate — framed against the compliance leaves.
Sub-merchant aggregation, where the acquirer’s liability sits and what the model changes about onboarding and settlement.
What tap-on-phone acceptance adds, its PCI MPoC scope and where it fits a merchant segment — grounded in the acquiring-softpos leaf.
The shape of interchange++ pass-through vs blended pricing — structure and trade-offs, never a contracted rate.
Every leaf in this surface — modes, rails, regions, compliance, training — is the agent’s primary context. It reasons over expert-approved content, not the open web.
Each leaf carries a named reviewer and a review date. The agent inherits that provenance: it can only stand on content a domain-expert partner has signed off.
Regulator directives, scheme bulletins and standards bodies are cited inline. The agent surfaces the source so the human can check it — never “trust me”.
The agent reads modes/acquiring-softpos and the compliance tree — PCI scope, KYC/CDD — all human-moderated content.
Acquiring is a risk business. Framing the product is safe; deciding who to onboard and at what price is not something to hand a model. The lines:
Whether to onboard a specific merchant, and at what risk tier, is a human credit-and-risk call. The agent frames the structure; it does not approve a merchant.
Interchange shifts, scheme fees change and pricing is negotiated. Treat the agent’s pricing as shape; the real number is set by a human and a contract.
PCI scope and PayFac eligibility carry compliance consequences. The agent points at the standard; a qualified human confirms scope.
Settlement, merchant limits and reserve decisions move money and carry risk — they stay with accountable humans, never the agent.
Reach for it early in product design — when you are shaping an onboarding flow, weighing a PayFac model, scoping SoftPOS for a segment or structuring a pricing approach. It compresses the “how does this normally work and what are the trade-offs” research so the team starts from structure, not a blank page.
Do not lean on it for the live decisions: underwriting a named merchant, setting a contracted rate, confirming PCI scope for an audit, or anything that moves money. There the agent is one input and a human risk owner is the decision. A mis-onboarded merchant or a mis-scoped PCI assessment is a real loss, so the human gate stays.