Multi-acquirer merchant onboarding without the email chain

Multi-acquirer merchant onboarding lets an ISO, PayFac or PSP collect one KYB questionnaire from a merchant and generate one application per acquiring partner, each carrying only the data selected for it. Acquirers ask their follow-up questions inside the application, so nothing waits in an inbox, and every decision is timestamped in the merchant file.

Today, merchant onboarding usually starts in a form and ends in an inbox. The acquirer's first follow-up question sends the file to email, and it rarely comes back. The gap exists because an operator onboards merchants for partners it does not control, and most onboarding tools have no seat for those partners. NORBr's Merchant Onboarding gives each party its own portal on the same merchant file. This article, updated in October 2026, covers what email costs, what the EU AML rulebook requires, and what changes when the partner works inside the file.

What does email-based merchant onboarding cost an ISO or PayFac?

Email turns every acquirer question into a delay that nobody measures. The main cost is time: while a file sits in a mailbox, the merchant is not processing, so the operator earns nothing on it. According to Mastercard's April 2024 report on digital merchant onboarding, based on research in Asia-Pacific, onboarding at traditional acquirers still relies on manual steps and back-and-forth over email and phone, and takes three to seven days on average.

Merchants notice. In the same Mastercard survey, onboarding time and a simple application process rank among the key considerations when a merchant chooses an acquirer.

The mailbox also imposes its own mechanics. Large attachments are refused or swapped for a transfer link that expires, and the audit trail expires with it. Once a question lives in a personal inbox, nobody can say how long it has been waiting, or on whom. When the analyst who owns the thread is on vacation, the merchant waits too.

Why does the EU AML Regulation make a shared inbox a liability?

The EU anti-money laundering Regulation sets retention and update obligations that an email thread cannot meet. The single AML rulebook, Regulation (EU) 2024/1624, applies from July 10, 2027, and two of its provisions bear directly on how onboarding files are kept.

Article 77 requires obliged entities to retain due diligence records for five years after the business relationship ends, and then to delete the personal data they contain. Article 26 requires customer information to be kept up to date, at least every year for higher-risk customers and at least every five years for all others. These obligations sit with regulated entities such as the payment institutions and acquirers that board merchants. Every party that collects files on their behalf holds copies of the same documents.

An inbox cannot meet either obligation. A director's passport sent as an attachment exists in the sender's mailbox, the recipient's, every forward and every synced device. No retention policy reaches all of those copies, and no deletion can be proven. Keeping a file current is no easier when the valid version of a document is whichever one someone found last.

How does a merchant go live across several acquirers?

A merchant goes live when every acquiring partner on its file has completed its own underwriting, and each partner restarts the loop. Behind most card acceptance sits a chain of organizations. An ISO (independent sales organization), a PayFac (payment facilitator) or a PSP runs the relationship with the merchant, and often receives it from an introducer, an agent or a referral partner paid to bring business in. The acquiring partner, the licensed institution that will settle the funds, takes the final risk decision.

A short pre-screen checks whether the merchant is worth a full review. The KYB questionnaire collects the legal entity, its ultimate beneficial owners (UBOs, the individuals who own or control it), the business model, bank details and supporting documents. The operator's team reviews the file and submits it to the acquirer, whose underwriters run their own due diligence and come back with questions.

One merchant often needs more than one partner, for instance an acquirer for cards and another for a local payment method. Each partner has its own requirements, and each one restarts the loop. This is legitimate work. Underwriting exists because the acquirer carries the risk. The friction comes from the channel those questions travel through.

Why do single-company KYB tools stop at the acquirer?

Most KYB and identity verification tools assume one organization, one file and one decision, so they have no place for the acquirer's underwriter. That design was built for a regulated company verifying its own customers, and it works well for a bank opening an account.

An ISO's onboarding has three or four organizations on a typical file and several decisions per merchant. A single-company tool has no place for the acquirer's underwriter to read the file or ask a question. It has no notion of one KYB feeding several applications, each carrying a different subset of data. Nor can it keep the operator's internal risk notes on one side and the partner's view on the other. So the follow-up question leaves the tool, and the answer comes back by email, if it comes back to the file at all.

What changes when the acquirer reviews inside the merchant file?

When the acquirer reviews inside the merchant file, the question, the answer and the decision stay attached to the record, with an author and a timestamp. NORBr's Merchant Onboarding treats the merchant file as the shared record and gives each party its own interface on it. Your team works in the program portal, where it builds forms, invites merchants, reviews files and generates applications. Introducers get an account and an invitation link per merchant, so attribution is recorded from the first click. Merchants complete their questionnaire, upload their documents and follow their applications. Payment partners open the applications routed to them in their own portal.

The merchant record and the application are two separate objects. The merchant answers once. The application is what travels. It is attached to one partner, carries the sections and documents you selected for it, and runs its own lifecycle from sent through due diligence to live. The partner sees that application and nothing else, so your internal risk notes and your pipeline stay out of view. Programs that keep their acquiring relationships private can hide partner identity from merchants, who then follow each application under a neutral label.

When an underwriter needs a missing UBO identity document, they ask inside the application. The merchant replies from its portal with a new file or one already in its vault, and the document is filed in the merchant record. Every message, share and decision carries an author and a timestamp, and time to decision becomes a number your team can track.

Documents are read on upload, and the extracted fields appear beside the scan for the analyst to check. An expired identity document is flagged the moment it lands. A challenged document keeps its history, and the merchant's replacement becomes version two. A submitted KYB is frozen until your team reopens it, so the file the partner reviews is the file you approved.

The platform does not approve anyone. Extraction and expiry checks prepare the review. The decision stays with your analysts, and underwriting stays with the acquirer.

Each merchant's documents sit in storage reserved for that merchant, encrypted under a managed key and kept in the EU, on an infrastructure listed on the Visa Global Registry of Service Providers. Each program sets how long documents and audit logs are kept, and both are removed automatically when the period ends, with the removal itself logged.

How does multi-acquirer onboarding work for operators with their own clients?

An operator that serves clients running their own merchant portfolios opens one sealed program per client, so each client onboards its merchants with its own forms, partners and users. The chain keeps getting longer. Software vendors are embedding payments and taking on the PayFac role, and Mastercard's 2024 report notes growing demand from these new entrants for platform-based onboarding. Operators also serve clients who run merchant portfolios of their own.

Each new layer adds a party to the email chain. On NORBr, an operator opens a program for a client, who onboards its own merchants inside it with its own forms, partners and users, and programs stay sealed from one another. The operator seeds a baseline of questions every merchant on its network must answer. Each client adds what its merchant mix calls for, such as sub-merchant structure for a marketplace or medical licensing for a clinic network. The whole journey runs under the brand agreed for that program, on a domain it owns, which is how a PSP or ISO can launch a branded onboarding experience for each client.

Can merchant onboarding run without moving the payment stack to NORBr?

Yes. Merchant Onboarding runs standalone, on the acquiring relationships you already hold, with no change to your processing setup. When your payment platform also runs on NORBr, an approved merchant moves into your payment stack with the information already collected, so the data entered once at KYB is the data used to activate processing.

Onboarding slows down wherever a second organization needs something from the file and has no way to ask for it there. Every question that cannot be asked in the file will be asked in an inbox.

NORBr Merchant Onboarding takes merchants from invitation to live under your brand, with one file shared across four portals and one application per payment partner. It runs standalone on your existing acquiring relationships, or connected to your payment stack on NORBr.