Merchant onboarding 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 ISO or a PayFac 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. The merchant completes one KYB (know your business) questionnaire. From it, you generate one application per acquiring partner, carrying only the data you chose to share. The partner asks for what is missing inside the application, and the merchant answers in the same thread.
The sections below cover the cost, the regulation, and what changes when the partner works inside the file.
What email costs a merchant onboarding team
Most of the cost is time, and time spent in onboarding is processing revenue that has not started. Mastercard's April 2024 report on digital merchant onboarding, based on research in Asia-Pacific, found that 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. The same report puts the cost of processing a single application at $250 to $350 for a traditional acquirer, against around $8 for a PayFac running a fully digital flow.
Merchants notice. In Mastercard's survey of merchants in the region, 30 to 35% named onboarding time and a simple application process as key considerations when choosing an acquirer.
The mailbox imposes its own mechanics. Gmail refuses attachments above 25 MB and swaps them for a Drive link. Microsoft caps Outlook at 20 MB for internet accounts, and at 10 MB by default on Exchange business mailboxes. A year of bank statements or a scanned shareholder register goes out as a transfer link that expires, and the audit trail expires with it.
Then there is visibility. 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 holiday, the merchant waits too.
Why the EU AML rulebook turns the shared inbox into a liability
The EU's single anti-money laundering rulebook, Regulation (EU) 2024/1624, applies from 10 July 2027. Two provisions bear 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 a merchant gets from first form to live across several acquirers
Behind most card acceptance sits a chain of organisations. An ISO (independent sales organisation), a PayFac (payment facilitator) or a PSP runs the relationship with the merchant, and often receives it from an introducer, an agent or 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 onboarding tools built for one company stop at the acquirer
Most KYB and identity verification tools were designed for a regulated company verifying its own customers. That design assumes one organisation, one file and one decision, and it works well for a bank opening an account.
An ISO's onboarding has three or four organisations 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
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. 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.
Merchant Onboarding runs standalone, on the acquiring relationships you already hold. When your payment platform also runs on NORBr, an approved merchant moves into your payment stack with the information already collected.
Why onboarding now runs through more layers than before
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.
Onboarding slows down wherever a second organisation 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.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
