One integration behind your global payments product.
You sell local collection, payout and FX rails to your customers. We build and run the bank connections underneath — across APAC and worldwide — so your engineers never touch a bank protocol and your product team ships new markets in weeks.
Every new market is another bank integration you have to build and babysit.
Your customers want to collect and pay out like a local in every market. But each bank ships its own API or SFTP spec — 300 pages, 40% out of date — and webhooks are never quite reliable. Your roadmap fills with bank plumbing. One country becomes a months-long project; keeping it working becomes a permanent tax.
We build and run every bank integration. You keep the customer and the custody.
We build it
Digest each bank's API/SFTP docs, build the connection, test every account, rail and currency pair before a payment moves.
We run it
Spec changes, deprecations and ISO 20022 migration are our job, not your on-call. Maintenance is the moat.
You stay the bank's customer
Tech layer, not a bank; you keep custody of funds and bank credentials.
Use cases
Local collections across markets
FAST, PayNow QR, eGIRO and regional rails.
Payouts & disbursements
FAST, MEPS, TT, GIRO / bulk.
Named static virtual accounts
COBO / POBO.
FX
Quotes and execution where banks support it.
Multi-bank / multi-region expansion
Add a bank or region without adding code.
If the money isn't matched in your bank account, it didn't happen.
One deduplicated stream across every bank and rail; static virtual accounts carrying your customer's name; statement fallback (CAMT.052 / .053) so nothing slips when a webhook misses.
Why Acme
One integration, every bank.
Done-for-you delivery.
Maintenance is the moat.
You keep custody.
APAC-led, global.
We sit under your stack
Below your TMS / ledger / ERP, behind your brand.
Static VAs with the customer's own name
A payments customer needed outbound payments to show the business customer's own name, plus bank redundancy beyond one provider. Acme delivers named COBO/POBO virtual accounts across multiple banks through one API.
Multi-bank redundancy
One pipe so you don't manage ten. Add a second or third bank for the same rail without rebuilding.
FAQ
Does Acme hold funds or sit in our flow of funds?
No. Acme is a non-regulated technology layer, not a bank, and never holds funds. Your merchants' and customers' money moves directly between banks and the accounts you hold in your own name; Acme only sends instructions and returns statuses and transaction data. You stay the bank's customer and keep your accounts and credentials. Acme stores credentials PGP-encrypted, per customer and per bank, and API keys can be scoped and restricted to your IP addresses.
Can we collect and pay out on behalf of our customers?
Yes, with named static virtual accounts. You create a virtual account for each business customer through the API, attaching their details for collections made on their behalf. Every incoming payment carries the virtual account number, so you can attribute it to the right customer, and virtual accounts also support paying out on your customers' behalf. Availability and naming rules vary by bank, so we confirm what each of your banks supports during scoping.
Which local rails can we offer our customers through Acme?
The main collection and payout rails in each market we cover. In Singapore, payouts run over FAST, PayNow, GIRO, MEPS and telegraphic transfer, and collections over eGIRO direct debit, PayNow QR codes and hosted payment pages. Elsewhere, examples include Hong Kong FPS and CHATS, Malaysian IBG and FPX direct debit, Australian high-value payments and UAE transfers. You can also verify account holders and look up PayNow proxies before paying. Rails differ by bank.
How do we keep our product running if a bank has an outage?
Build for it with clear signals and a second bank. When a bank is under scheduled maintenance, Acme's API returns HTTP 503 with "Bank is under maintenance", so you can queue or reroute payments rather than guess. You can connect a second or third bank for the same rail through the same API, without rebuilding. Acme itself commits to 99.5% monthly uptime and publishes live status at status.tryacme.com.
How does reconciliation work across banks and rails?
Every bank's data arrives as one normalised transaction stream. Acme ingests real-time notifications, intraday statements and end-of-day statements, deduplicates them and exposes each transaction once through the same API and webhooks, with the counterparty, reference and virtual account number. If a real-time notification is missed, the transaction still arrives from the statement. Payouts also carry the bank's own reference, so you can match each one to the bank's record.
How fast can we launch a new market or bank?
Typically 6–8 weeks per bank, versus 6–10 months in-house. Acme reads the bank's specifications, builds and tests the connection and manages the bank-side project, while your team integrates once against our REST API, starting in test mode. Adding a bank or market later uses the same API, with bank-specific fields documented per bank. After go-live, Acme handles bank changes and migrations such as ISO 20022, and announces any new required fields in our changelog.