Payment onboarding is complete when the customer can execute, control and reconcile the intended flow. A provider approving a know-your-business file is an important milestone, but it is not the same as an operational payment service. For a group with several legal entities, the gap can be substantial.
This report merges three historical infrastructure and onboarding studies, including material current through July 2026. Names and specific institutional relationships have been removed. Timelines and economics retain their status as historical estimates, public case claims or explicit illustrations. The argument is to evaluate providers against the customer’s entire implementation rather than the narrow interval a supplier chooses to call onboarding.
Two entities can create more than twice the work
A group structure introduces distinct legal owners, signatories, beneficial ownership chains, funding arrangements, permitted products and jurisdictions. Some information can be reused, but the provider still has to establish which entity is the customer and which entity is authorised to perform each activity.
Central treasury may coordinate the programme without becoming the legal owner of every account or payment obligation. A group administrator may be allowed to view several entities but not approve transactions for all of them. These distinctions must be represented in the platform rather than handled through informal workarounds.
Joint ventures and complex ownership structures can create additional questions. The source studies described them as particularly slow cases because ownership, control and signatory authority can be ambiguous. A complete group document pack does not automatically resolve entity-specific requirements.
Distinguish the clocks
Different onboarding clocks measure different scopes — Clock: Commercial selection
| Measure | Value |
|---|---|
| Starts | Initial evaluation |
| Ends | Contract approval |
| Typical missing work | Product suitability and operating design |
Different onboarding clocks measure different scopes — Clock: KYB review
| Measure | Value |
|---|---|
| Starts | Complete entity submission |
| Ends | Entity approval |
| Typical missing work | Integration and production controls |
Different onboarding clocks measure different scopes — Clock: Technical implementation
| Measure | Value |
|---|---|
| Starts | Interface and data work |
| Ends | Tested production connection |
| Typical missing work | User readiness and finance reconciliation |
Different onboarding clocks measure different scopes — Clock: Operating readiness
| Measure | Value |
|---|---|
| Starts | Roles and procedures defined |
| Ends | Controlled live operation |
| Typical missing work | Continuing exceptions and rollout |
Different onboarding clocks measure different scopes — Clock: Group rollout
| Measure | Value |
|---|---|
| Starts | First entity mobilisation |
| Ends | Intended entities and flows operating |
| Typical missing work | Local requirements and migration |
Historical source ranges included
Historical timeline ranges measure different implementation scopes
| Aspect | Retained observation |
|---|---|
| Entity onboarding | approximately 1–12 weeks for an entity’s onboarding, |
| Mid-market implementation | 5–9 months for some mid-market implementations |
| End-to-end programme | and 6 weeks to 18 months for broader end-to-end programmes. |
These describe different scopes and cannot be averaged into one universal onboarding time. Joint-venture examples were placed around 8–16 weeks, with a tail of roughly 26 weeks.
The source also suggested that 60–75% of group-level information might be reusable. That is an estimate of potential reuse, not an assurance that every provider or jurisdiction accepts the same documents. Reuse must preserve freshness, provenance and legal-entity relevance.
Figure 01 · Conceptual framework
Onboarding an entity into a usable money flow
Begin with the intended money flow
Outgoing supplier payments, payroll, merchant collections, virtual accounts, cards and cross-border transfers require different capabilities. A platform can be excellent for one and unsuitable for another. The project should map the payer, payee, account owner, currency, settlement route and reconciliation record before procurement.
For collections, identify how incoming funds are attributed to the correct customer and legal entity. Virtual account structures can simplify reconciliation, but their legal and operational meaning must be understood. A virtual identifier is not necessarily a separate bank account with independent legal characteristics.
Different payment flows require different control definitions
| Aspect | Retained observation |
|---|---|
| Outgoing payments | For outgoing payments, define approval rules, payment limits, funding, cut-offs, sanctions review and exception ownership. |
| Cards | For cards, define programme ownership, eligible users, spend controls, funding and disputes. |
| Cross-border flows | For cross-border flows, add conversion timing, local payout arrangements, prefunding and the final beneficiary experience. |
Permissions are part of the financial control
A multi-entity platform needs roles that reflect actual authority. Separate administrators, preparers, approvers, viewers and technical service accounts. Where dual approval is required, the design should prevent one individual from bypassing it through several roles or credentials.
Access should be scoped to entities, accounts, products and actions. A user permitted to view a subsidiary’s balance should not automatically be able to change its beneficiaries. API credentials need the same discipline as human access, including rotation, monitoring and controlled changes.
Test onboarding and offboarding of users. A departing employee’s access should be removed across the relevant entities. Group changes, acquisitions and divestitures also require a permission transition plan. The platform should support the operating model as it changes, rather than assuming the initial hierarchy remains permanent.
Integration quality determines operating effort
Payment creation is only one API function. The customer also needs status, returns, fees, settlement records, balances and reconciliation evidence. Inconsistent identifiers or missing events create manual investigations after the payment has apparently succeeded.
Use a canonical transaction identifier across the internal request, provider response, settlement record and accounting entry. Distinguish an accepted instruction from a completed payment. Delayed or duplicated events should be handled without creating duplicate transfers or losing the final outcome.
The test plan should include rejected payments, partial information, changed beneficiaries, insufficient funds, currency conversion, returned funds and a provider outage. A production integration is defined by its handling of exceptions as much as by the happy path.
Figure 02 · Qualitative comparison
Three clocks hidden inside onboarding
| Approach or concept | What it contributes | What still matters |
|---|---|---|
| Compliance approval | Determines whether the entity can be served | Does not prove technical readiness |
| Technical integration | Connects APIs, accounts and events | Does not prove treasury permissions work |
| Operational readiness | Enables controlled payment and reconciliation | Needs rehearsed exception handling |
“Instant” needs an end-to-end definition
The July 2026 source cited historical cross-border analysis in which
Historical one-hour crediting measures and the cited target
| Aspect | Retained observation |
|---|---|
| Retail payments | only about 35% of retail payments |
| Wholesale and remittance payments | and 55% of wholesale and remittance payments were credited within one hour, |
| Target | compared with a 75% target. |
Those figures refer to the cited historical population; they are not a current performance statement for every corridor.
The relevance is that rapid initiation or inter-provider transmission does not necessarily mean rapid beneficiary credit. Compliance review, local operating hours, conversion, receiving-bank processes and missing information can still delay the outcome.
A provider should state which segment of the journey its speed claim measures. Buyers should measure successful beneficiary receipt, including exceptions, rather than relying only on an API acknowledgement. The commercial benefit of a faster route also depends on reliability and transparency when it fails.
Total cost can reverse a unit-fee ranking
The source included an explicit illustration in which one provider charged 10–15% more in direct fees but required less prefunding, reduced manual reconciliation and supported a reusable entity hierarchy. This was a teaching comparison, not an observed customer contract. It shows why a lower transaction fee can produce a higher total cost.
Let be direct provider fees, liquidity and prefunding cost, internal operating cost, implementation cost and the expected cost of operational failures. A simplified programme comparison is
The components need a common period. A one-time implementation cost should not be compared directly with an annual subscription without amortisation or present-value treatment. Expected failure costs should be shown as scenarios when evidence is weak, not forced into a precise number.
Public case examples in the original research described banking-cost reductions of 30–40% from account rationalisation. Those are reported outcomes from particular implementations, not a general promise. The buyer should establish which accounts can actually close and which operating costs disappear.
Figure 03 · Conceptual framework
Is the entity ready for a rollout wave?
How the parts connect
- Entity onboarding statusPath AAll critical controls proven
- Entity onboarding statusPath BOne clock incomplete
- All critical controls provenReviewReusable entity record
- One clock incompleteReviewReusable entity record
A provider scorecard should follow the whole programme
Evaluate legal and product fit, geographic coverage, onboarding requirements, access control, API quality, settlement information, support, resilience and total economics. A supplier that approves simple entities quickly may still be a poor fit for a complex group. A slower initial process can be acceptable if it produces a reliable reusable operating structure.
Ask for the exact documents and decisions required for each entity archetype. Identify which items can be reused and which must be refreshed. Require a clear process for stalled cases and a named owner who can coordinate commercial, compliance and technical teams.
The implementation plan should include customer dependencies. A provider cannot complete an integration if the customer’s finance mapping, approval policy or source data is unresolved. Making those dependencies explicit improves the schedule and prevents a misleading comparison of supplier performance.
Roll out by controlled waves
Begin with a bounded entity and payment flow that still represents the target architecture. Avoid a pilot so simple that it proves little about the intended group. Establish reconciliation, incident handling and finance sign-off before expanding volume.
The next wave should test a materially different requirement, such as another currency, a more complex ownership structure or a different approval model. Reuse proven components while documenting the differences. Each wave needs acceptance criteria based on completed payments and controlled exceptions.
Maintain a migration plan for existing accounts and processes. Running old and new providers in parallel can be necessary, but the programme should define when duplication ends. Otherwise account rationalisation remains a promised benefit while costs and operational complexity persist.
Design the reusable entity record
A reusable record should distinguish group facts from entity facts. Group ownership information may be common, while a subsidiary’s registration, authorised signatories, tax identifiers, operating purpose and account mandates are specific. Each item needs a source, review date and a rule for when it must be refreshed.
Reusing information should not mean copying an old document into a new application without checking whether it remains valid. A change in ownership or control may affect several entities. A signatory change may affect only selected accounts. The platform should support those relationships so updates reach the right places without creating unnecessary reviews elsewhere.
Document reuse and approval reuse are also different. A provider may accept the same evidence while still performing an entity-specific decision. This is a legitimate distinction, but it should be clear in the proposed timeline. Marketing claims about instant onboarding often hide the assumptions that the entity is simple, the documents are complete and the intended product is already supported.
The customer’s internal data owner should maintain the reusable record independently of any single provider where feasible. That reduces repeated preparation and improves the ability to compare suppliers. It also provides a clearer exit path if the group later changes its banking or payment arrangements. The purpose is a maintained information asset, not merely a larger folder of documents.
Metrics that reveal the real result
Record the reasons for delay as well as elapsed time. Missing customer information, provider review and unresolved technical work require different corrective actions and should not share an unexplained status.
Track time from mobilisation to first controlled live payment, time to complete the intended rollout, entity approval time, rejection and return rates, manual touches, reconciliation breaks and cost per successful payment. Segment results by entity and corridor so a smooth majority does not hide a difficult minority.
Customer abandonment and document rework are useful onboarding measures. Production measures should include failed approvals, duplicate instructions, unresolved status and incident recovery. The strongest dashboard connects the onboarding process to the quality of the eventual operating service.
The comprehensive payment platform is therefore one that supports the group’s legal structure, control model and end-to-end money flows. Speed remains valuable, but the relevant clock ends when the customer can operate reliably. Measuring that clock produces a more defensible provider choice than accepting a narrow KYB approval claim as the whole implementation.
