API banking · for finance and engineering
Your bank account, operated from your own systems
Balances, statements and transfers without logging in to a portal: read by your ERP, triggered by your product, approved by your finance team. This guide covers what's usually possible, how to keep it safe, and how to run it every day.
- → get balance account ••4410
← ₹48,20,115.40 available - → get statement today
← 3 entries - → transfer ₹2,40,000 · RTGS · ref PAY-7781
← accepted, awaiting approval → approved - → get status ref PAY-7781
← processed · UTR received
Current account ••4410
Illustrative- 09:14UPI collections settlement+1,12,400.00
- 11:02NEFT from Shreeji Traders+48,500.00
- 12:40Bank charges−590.00
- 14:05RTGS to Kaveri Packaging · PAY-7781−2,40,000.00
From portal clicks to system calls
Most businesses run their bank account through the bank's portal: download a statement, upload a payment file, approve, repeat. It works until volume grows, or until someone needs the balance at 11pm, or until the statement has to be keyed into the accounting system by hand.
API banking lets the systems that already know what should happen talk to the bank directly. The account is still yours, at your bank, under your mandate. What changes is who does the repetitive work, and how quickly information moves.
Access can come directly from a bank, or through a platform connected to one or more banks. Which banks Peneu connects to, and on what basis, is confirmed during onboarding.
| Capability | Replaces |
|---|---|
| Balance | Logging in to check |
| Statement | Downloading and uploading files |
| Transfers | Payment files and portal approvals for routine payments |
| Transfer status | Calling the bank about a payment |
| Incoming credit notifications | Refreshing the statement |
| Collections accounts | Matching credits by hand (see virtual accounts) |
Commonly offered by banks; availability differs by bank and is confirmed during onboarding.
Balances and statements: the quiet workhorses
The most valuable API is often the least exciting: the statement. Fed straight into your accounting or reconciliation system, it removes the daily download, the file format fights and the typos, and it means the books can be closed from data rather than from exports.
Decide how often you need it. Some teams pull the statement a few times a day; others use notifications as credits arrive and pull a full statement once at day end to be sure nothing was missed. Either way, reconcile against the full statement: a notification is a prompt, not a ledger.
Store every line once. Statement entries have their own references; use them to avoid importing a line twice.
Keep the bank's text. The narration often holds the payer's name or your reference.
Close with the full statement. Notifications can be missed; the day-end statement can't.
Transfers by API, with the controls of a portal
A transfer sent by API travels on the same rails as one sent from the portal: IMPS, NEFT, RTGS or UPI, with the same statuses and bank references. What has to be rebuilt is the control that the portal gave you for free: a person looking at it before it goes.
- 01
Create
Your system creates the transfer with its own unique reference.
- 02
Check
Limits, beneficiary verification, duplicate reference.
- 03
Approve
Automatic below your limits; a person above them.
- 04
Send
Released on the rail that fits the amount and urgency.
- 05
Confirm
Status checked until final; bank reference stored.
Rails, statuses and what to do when a transfer goes quiet are covered in the payouts guide; many transfers at once in bulk payouts.
What's in a statement line, and what trips people up
A statement line looks simple: a date, a description, an amount, a balance. Automating it exposes the details a person reading a PDF never notices. Two dates can differ: the date the bank recorded the entry and the value date from which it counts. The description is free text written by the payer's bank, the rail and sometimes the payer, so the same customer's payments can look different every month.
Build matching on the stable parts first: amounts, the bank's own reference, and virtual account numbers where you use them. Treat the description as a hint, not a key. And never import a statement without checking that the opening balance equals yesterday's closing balance; if it doesn't, something is missing.
- Posting date
- When the bank recorded it
- Value date
- From when it counts for balance and interest
- Description
- Free text: payer name, rail, sometimes your reference
- Bank reference
- The bank's own ID for the entry; your de-duplication key
- Debit or credit
- With the amount
- Running balance
- Lets you prove nothing is missing
Typical fields; exact names and formats differ by bank.
The timeout problem: making a retried transfer safe
The most dangerous moment in API banking is a transfer request that times out. Your system doesn't know whether the bank received it. Sending it again might pay twice; not sending it might not pay at all.
The answer is to make every transfer identifiable before it's sent. Give it your own unique reference and store it first. If the request times out, ask the bank for the status of that reference before doing anything else. Only when the bank confirms it never received it, or that it failed, do you send it again, and then as a new attempt linked to the original. Whether a given bank rejects a repeated reference on its own differs; don't rely on it without confirming.
Who presses the button
In a portal, a person approves each payment. With an API, your own software decides, so the approval rules move into your systems, and they need the same rigour a bank's would. The question isn't whether to automate approvals, but which payments are routine enough to go without a person.
Adding a new beneficiary deserves the most care. Most payment fraud starts with a new or changed account, so a new beneficiary should need a second person, even when payments to known beneficiaries flow automatically.
| Transfer | Approval |
|---|---|
| To a known beneficiary, within daily limits | Automatic |
| Above a per-transfer limit | One person |
| Above a daily total | Two people |
| To a new or changed beneficiary | Second person approves the beneficiary first |
| Outside business hours | Automatic only for listed payment types |
Illustrative rules. Set limits to your size and risk.
Rolling it out in phases
Teams that start with transfers often spend their first month firefighting. Teams that start by reading data learn how the bank behaves before anything can go wrong. A phased rollout costs a few weeks and saves most of the surprises.
- Phase 1
Read
Balances and statements into your systems. Nothing can move money yet.
- Phase 2
Reconcile
Automate matching; run it beside the old process until they agree.
- Phase 3
Pay, small
Transfers to known beneficiaries, with low limits and every one watched.
- Phase 4
Scale
Raise limits, add rails and payment types as the controls prove themselves.
Security: assume every mistake happens at machine speed
An API that can move money is only as safe as the weakest place its credentials live. The practices below are common across banks and platforms. The exact requirements for your connection are set by the bank and confirmed during onboarding.
Restricted network access
Requests accepted only from your known servers, for example by IP allow-listing.
Strong request authentication
Certificates or signed requests, not just a key that can be copied.
Secrets kept out of code
Credentials in a secrets store, rotated on a schedule and when people leave.
Separate read and pay
Systems that only need statements can't send transfers.
Limits and approvals
Per-transfer and daily limits; people approve above them.
Monitoring
Alerts on unusual volumes, new beneficiaries and failed authentications.
Knowing when money arrives
For collections, the question is always “has it come in?”. Notifications of incoming credits let your product act the moment money lands: release an order, mark an invoice paid, credit a customer's wallet.
Pair them with a way to tell who paid. A single account receiving thousands of transfers is hard to match; giving each customer their own virtual account number solves most of it. See virtual accounts.
Notification arrives
Treat it as a prompt; confirm against the account before acting on large amounts.
Match it
By virtual account, reference or amount.
Act
Release, mark paid, credit.
Close the day
Every credit on the statement is matched or in exceptions.
More than one bank
Many businesses bank with more than one bank, by choice or by history. Each bank's APIs have their own formats, statuses, limits and maintenance windows. Connecting them one by one means maintaining several integrations; connecting through one layer means your systems see one format.
| Reason | What it looks like | What to watch |
|---|---|---|
| Resilience | Payouts continue through a second bank during an outage | A transfer already sent through the slow bank stays there until it's final |
| Strengths | Collections at one bank, payouts at another | Moving funds between them in time |
| Group structure | Each company banks separately | Consolidated view without mixing entities |
| Lending relationships | Accounts required by a lender | Balances spread thin across accounts |
How payouts can move between banking partners: automatic failover.
Treasury and ERP: where the value compounds
Once balances and statements flow automatically, finance teams can answer questions that used to take a day: how much cash do we have across all accounts right now, what cleared today, what's due out tomorrow. Payments approved in the ERP can be sent without re-keying, and their bank references flow back to mark invoices paid.
Cash position. Balances across banks and entities, updated through the day.
Payables. Approved invoices paid from the ERP, references written back.
Receivables. Credits matched to invoices as they arrive.
Close. Month end from data, not exports.
Running it day to day
Banks have maintenance windows, rails have their own rhythms, and APIs occasionally time out. None of this should reach your customers or your finance team as a surprise. Plan for three things: what your systems do when the bank doesn't answer (queue and retry reads; never blindly resend a transfer), who is alerted when something stays stuck, and how you'll know the bank has announced maintenance.
NEFT and RTGS themselves run round the clock on every day of the year, according to RBI's FAQs, so “bank holiday” no longer means “no transfers”. But your bank's own processes, and your approvers, may still keep office hours.
Testing before real money moves
Banks usually provide a test environment for API integrations, and testing there is where the edge cases should be found: timeouts, rejected transfers, duplicate references, statements with unusual entries. Test the unhappy paths more than the happy one, because production will.
Test environments rarely behave exactly like production, so plan a first live week with small amounts and someone watching every transaction. The goal of that week isn't volume; it's proof that your reconciliation catches everything.
Timeout on a transfer
Status enquiry first; no resend.
Rejected transfer
Reason recorded; beneficiary fixed; new reference.
Duplicate reference
Caught before it reaches the bank.
Statement gap
Opening balance doesn't match yesterday's close: alert.
Expired credentials
Rotation doesn't stop the business.
What to watch once it's live
Once API banking is running, the risk shifts from building it to noticing when it quietly stops working. Watch a handful of signals: transfers stuck in a non-final status for longer than usual, statements that didn't arrive on schedule, failed authentications, unusual spikes in transfer volume, and new beneficiaries added outside normal hours. Each should reach a named person, not a shared inbox.
Direct to each bank, or through one layer?
Direct
Full control and a direct relationship. Suits a business with one bank and an engineering team to maintain the integration, its certificates and its changes.
Through a platform
One integration, one format, several banks behind it. Suits businesses with more than one bank, or that would rather not maintain bank-specific code. The platform's role and the banks it connects are what to check first.
How payment APIs get abused, and what stops it
The threats to a payment API are rarely clever. They are stolen credentials, a compromised server that already has them, and a trusted insider adding a beneficiary they control. Each has a plain countermeasure, and all of them sit on your side of the connection.
| Threat | Control |
|---|---|
| Credentials copied from code or a laptop | Secrets store, rotation, and network restrictions so copied keys don't work elsewhere |
| A compromised application server | Separate read and pay credentials; limits the server itself can't raise |
| An insider adds a new beneficiary | Second-person approval for beneficiaries; alerts on first payments |
| Slow drain below approval limits | Daily totals, velocity alerts and reconciliation against expected payments |
Every bank speaks a slightly different dialect
Two banks can describe the same transfer differently: different status names, different field names, different ways of writing a narration, and different ideas of when a transfer is “done”. If your systems read each bank's responses directly, every bank you add doubles the edge cases.
The fix is a thin translation layer of your own: map each bank's statuses to a small set of states your business understands, keep the bank's original status and text alongside for support and audit, and never let a status you haven't mapped be treated as success.
| Your state | Means | Unknown bank status goes to |
|---|---|---|
| Sent | Accepted by the bank; outcome not final | — |
| Completed | Final, with a bank reference | Never |
| Failed | Final, not paid, with a reason | Never |
| Needs attention | Anything unexpected or unmapped | Here, with an alert |
Illustrative states for your own system; bank status names differ and aren't listed here.
API banking questions
Can payroll or supplier runs go through API banking?
Yes. A batch of transfers can be sent through the API instead of a file upload, with the same approvals. Many businesses start with supplier runs from their ERP, then move payroll once the controls are proven.
What happens during a bank's maintenance window?
Some or all API calls may be unavailable for the window. Your systems should queue reads and retry later, hold new transfers or route them to another bank if you have one, and never resend a transfer whose status is unknown.
What is API banking?
Operating a business bank account from your own software instead of the bank's portal: reading balances and statements, sending transfers and learning about incoming credits through APIs, so your ERP, treasury or product systems work with the bank directly.
Does API banking replace the bank's portal?
Usually not. The portal stays for things people do occasionally, like approving unusual transfers or downloading certificates. APIs take over the repetitive, high-volume work, which is where manual effort and errors pile up.
Is it safe to send payments by API?
It can be, with the right controls: restricted network access, strong authentication of every request, approvals for transfers above limits your business sets, unique references so a retry can't pay twice, and monitoring. Weak controls on a payment API are riskier than a portal, because mistakes happen at machine speed.
How quickly do I see incoming money?
As fast as the bank reports it: some setups notify you as credits arrive, others let you fetch the statement as often as you need. The rail the payer used decides when the credit itself lands.
Why would a business connect more than one bank?
For resilience, for different banks' strengths (collections with one, payouts with another), and because group companies often bank separately. The cost is that each bank's APIs differ, which a single integration layer can hide.
Which banks and API capabilities does Peneu provide?
Which banks are connected, and which capabilities (balances, statements, transfers, notifications) are available, is confirmed during onboarding. Peneu isn't claimed here to hold or operate your bank account.
Official sources
Last reviewed . Examples, amounts and screens marked illustrative are not Peneu figures.