Article map
A payment factory promises standardisation, lower bank complexity, stronger control and better visibility. Yet centralisation can also create distance from the business obligation, a single operational dependency and uncertainty about which entity owns the payment. The outcome depends less on organisational location than on the operating model.
A mature payment factory is a governed service. It defines what is centralised, what remains local, which legal entity pays, how instructions enter, how approvals operate, how banks respond and how settlement returns to source accounting. This article presents the design choices required.
1. Define the service outcome
The case for a payment factory may include fewer bank channels, standard controls, increased straight-through processing, lower manual effort, improved fraud prevention, central liquidity management and consistent status visibility.
Each objective should have a baseline and measurable target. “Centralise payments” is not an outcome by itself. The programme should specify which pain points will change and which risks must not increase.
The target may differ by payment type. Supplier, payroll, tax, treasury, intercompany and urgent payments can follow different service paths.
2. Choose the centralisation model
Several models are possible. A technology hub can transmit payments while local teams prepare and approve. A shared service can prepare and validate while legal entities approve. A central treasury can manage payment-on-behalf-of structures, subject to legal, tax and accounting design.
The model can also vary by country. Regulatory or banking constraints may require local execution while retaining common controls and reporting.
The choice should be explicit. Ambiguity about whether the factory acts as operator, agent or principal creates legal, accounting and accountability risk.
3. Preserve legal-entity authority
The entity that owes the obligation should have authorised the payment in accordance with its governance, even where a central service executes it. Bank mandates, powers of attorney, service agreements and delegation should align.
Payment-on-behalf-of arrangements may create intercompany balances, disclosure, tax, documentation and beneficiary-reference considerations. The beneficiary should be able to identify the underlying payer and invoice.
Entity boards and management should understand the service, escalation rights and contingency arrangements.
4. Define the service catalogue
The factory should publish which payment types, currencies, countries, banks and channels it supports. It should state cut-offs, required data, exception routes, approval responsibilities and service levels.
A clear catalogue avoids uncontrolled local workarounds when a payment falls outside scope. It also supports phased onboarding.
Services may include beneficiary validation, payment formatting, bank routing, sanctions screening support, bank-status monitoring, reconciliation, reporting and incident coordination. Responsibility for each should be stated.
5. Standardise source intake
Instructions should originate from approved ERP, payroll, tax, treasury and other source systems. Interfaces should carry unique references, legal entity, beneficiary, amount, currency, purpose, due date and approval status.
The factory should not become a general mailbox for spreadsheets and emails. Where manual files remain, templates, encryption, validation, access and approval must be controlled.
Source acknowledgement is important. The originating system should know whether a batch was received, rejected, accepted or settled.
6. Build one canonical payment model
Different systems and banks use different fields and formats. A canonical model allows common validation, workflow, routing and reporting while preserving source and bank-native data.
The model should support payment type, priority, remittance, charges, regulatory information, end-to-end identifier and status. It should also retain local fields where required.
Canonical design should not reduce data to the lowest common denominator. It should support the richest business lifecycle and transform outward to bank-specific formats.
7. Separate obligation approval from execution approval
The source system may approve the invoice or payroll. The factory validates and routes the payment. Treasury may approve account use or funding, while bank signers authorise release.
These approvals serve different assertions and should not be duplicated without purpose. Equally, the factory should not assume a source approval covers beneficiary change or bank-account selection.
A control matrix should map each approval to the risk it addresses and identify where reliance on source controls is permitted.
8. Apply standard risk and policy rules
The factory can enforce consistent duplicate checks, beneficiary controls, amount thresholds, account permissions, cut-offs, sanction or compliance checks, maker-checker and urgent-payment rules.
Rules should allow legal-entity and jurisdiction variation through governed configuration. Hard-coded exceptions become difficult to maintain.
Rule changes should be tested against historical payments, approved and effective-dated. A central factory amplifies both good and bad configuration.
9. Optimise routing and bank connectivity
Routing can consider entity account, currency, bank capability, payment method, cut-off, cost and priority. The decision should remain transparent and within mandate.
Connectivity may use APIs, host-to-host, SWIFT and portals. The factory should monitor file or message creation, transmission, acknowledgement, rejection, settlement and return.
Bank-format change should be managed centrally with certification and fallback. This is one of the major scale benefits of the factory.
10. Integrate liquidity and funding
Central visibility of payment queues allows treasury to forecast account outflows, fund accounts, optimise sweeps and avoid rejected payments. The factory should provide time and status data to the cash position.
Funding decisions should not silently delay valid obligations. A policy hold, liquidity hold and technical hold should be separately identified.
Payment-on-behalf-of structures require clear settlement and intercompany funding. The central paying entity should not become an unmonitored lender.
11. Manage exceptions through a central queue
The factory should normalise bank rejections, source errors, duplicates, missing approvals, insufficient funds and pending items into a common exception taxonomy.
Ownership may remain local for commercial data and central for technical or bank issues. The queue should route accordingly and track service level.
Repair must preserve original instruction and approval. Material changes should restart relevant controls.
12. Reconcile to source and accounting
Settlement status and bank transactions should return to the originating system. The factory should match payment instruction, bank debit, fees, returns and accounting entries.
Where a central entity pays on behalf of another, intercompany accounting should be generated and reconciled. Remittance and beneficiary communication should identify the original obligation.
The service is not complete until source systems and ledgers reflect the bank outcome.
13. Design service levels around business deadlines
Service levels should distinguish receipt, validation, approval, transmission, bank acceptance, exception response and settlement. A single “same-day payment” measure is too broad.
Cut-off service levels should incorporate time zone, currency calendar and bank processing. Late source submission should be distinguished from factory delay.
Metrics should be transparent to participants so that improvement is shared rather than disputed.
14. Build resilience for central dependency
Centralisation concentrates operational risk. The factory needs redundant connectivity, alternate bank channels, recovery procedures, trained staff, secure remote access and incident communication.
Fallback should preserve entity authority and dual control. Local teams should know when they may invoke emergency routes and how activity will be reconciled afterward.
Resilience testing should include end-to-end payment completion, not merely system availability.
15. Govern onboarding and change
Entities should be onboarded through readiness assessment covering source quality, beneficiary master, bank accounts, mandates, formats, controls, cut-offs and local requirements.
Parallel testing should reconcile counts, values, statuses and accounting. Exit criteria should be defined before local processes are retired.
New banks, entities, payment types and rules should follow controlled release management. The factory should not become a permanent project with undocumented customisations.
16. Operate as a service with transparent economics
Costs can include platform, connectivity, bank fees, staffing and change. Benefits include lower manual work, reduced portals, better cash use, fewer failures and stronger control.
A chargeback or allocation model should be understandable and avoid discouraging use of the controlled service. Participants should see service performance and improvement roadmap.
The factory needs product ownership after go-live so that standards, banks and business requirements continue to evolve.
Design legal-entity settlement and internal service economics
The central service should distinguish the entity that initiates the obligation, the entity whose bank account settles it and the entity that bears the operating cost. In a standard central-technology model these may remain the same legal payer. In a payment-on-behalf-of structure, the paying entity may create an intercompany receivable and the underlying entity must recognise the liability settlement and internal funding movement. The operating design should therefore state the principal or agent relationship, accounting entries, remittance content, intercompany settlement frequency and responsibility for bank charges.
Service economics also influence behaviour. A chargeback based only on transaction count may discourage consolidation or encourage local bypass. A better model can separate fixed platform cost, variable bank or processing cost and exceptional manual service. The service catalogue should show which cost is avoidable and which reflects a control requirement. Transparency helps participants compare the controlled factory with local alternatives on a like-for-like basis.
Manage capacity, demand and seasonal peaks
Centralisation concentrates workload as well as control. The factory should forecast payment volume by entity, type, cut-off and seasonal event such as payroll, tax, dividend or acquisition. Staffing, system throughput, bank limits and approver availability should be tested against peak—not average—demand.
Capacity plans should identify which activities can be automated, which need skilled investigation and which require senior approval. A surge process can pre-validate files, extend coverage and prioritise critical payments without weakening segregation. Post-peak review should compare forecast and actual workload and update the operating plan.
Practical illustration: central execution, local obligation ownership
A group has twelve ERPs and thirty bank portals. Local teams approve invoices and manually upload payment files. The factory introduces canonical intake, central validation, standard approval evidence and host-to-host transmission, while each entity continues paying from its own accounts.
Local finance owns obligation and beneficiary accuracy. The factory owns formatting, routing, bank status and technical exceptions. Treasury uses the consolidated queue to fund accounts. Bank portals are retained only as controlled fallback. The group gains central visibility without pretending that legal-entity responsibility has disappeared.
Implementation checklist
A payment factory operating model should include:
- measurable service objectives and baseline;
- explicit technology, shared-service or payment-on-behalf-of model;
- legal authority and entity accountability;
- published payment-type and country service catalogue;
- approved source channels and acknowledgements;
- canonical payment and status model;
- control matrix separating obligation and execution approvals;
- configurable risk and policy rules;
- transparent bank routing and connectivity monitoring;
- liquidity, sweep and funding integration;
- central exception taxonomy with correct ownership;
- source, bank and ledger reconciliation;
- stage-specific service levels;
- tested end-to-end resilience;
- controlled onboarding and release management; and
- transparent cost, benefit and product governance.
Common operating-model failures
Common failures include centralising file upload without centralising status and control, assuming central execution transfers obligation ownership, supporting every local exception indefinitely, failing to return settlement to source, relying on one connectivity route and measuring success by payment volume alone.
Another failure is creating a central team that performs manual work previously distributed across entities. A true factory standardises data and workflow rather than merely relocating spreadsheets.
Closing perspective
A payment factory is an enterprise service that connects local obligations with standard validation, approval, bank execution, settlement and evidence. Its effectiveness depends on clear boundaries between entity ownership and central operation.
When the service model, legal authority, data, controls, connectivity, reconciliation and resilience are designed together, centralisation can improve speed and control without distancing treasury from the business reality behind each payment.
Frequently asked questions
What is a corporate payment factory?
A payment factory is a central operating capability that standardises payment preparation, validation, approval support, bank transmission, status and reconciliation across multiple entities or systems.
Does a payment factory mean one entity pays every obligation?
Not necessarily. It may centralise technology and operations while each entity pays from its own account, or it may use payment-on-behalf-of structures where legally and operationally appropriate.
What should remain locally owned?
The business and legal entity should retain ownership of the underlying obligation, commercial approval, local regulatory requirements and timely provision of accurate source data.