Bank APIs
- Balances and transactions on demand
- Payment initiation and status by API call
- Credentials and certificates per bank
- Coverage that differs by bank and country
Treasury Management
Treasury management software development
Treasury teams log in to several bank portals each morning, copy balances into a spreadsheet and send payment files by hand. Agnotic Technologies builds treasury and cash management software that collects statements from every bank, builds the daily cash position and sends approved payments in each bank's format.
Bank APIs, SFTP and SwiftISO 20022 and BTRSCash forecastingDual approval and screening
Trusted by global innovators
What is treasury management software?
Treasury management software gives a company's treasury team one view of cash across every bank account, sends payment files to its banks and forecasts liquidity from payables, receivables and payroll. Agnotic Technologies builds treasury management software for corporate treasury teams, connected to each bank by API, host-to-host file transfer or Swift, with approvals and sanctions checks on every payment.
This is software for a company's own cash, not for a bank's customers. Retail banking features sit on our digital banking platform page, and card acceptance sits with our payment gateway integration services.
Cash management software is the daily half of the job: where the cash is this morning and where it will be next week. Treasury management adds the payment run, bank account administration and the controls auditors ask about.
We build both in one system, because a forecast is only as good as the cash position it starts from.
Cash positioning
How is the daily cash position built?
The morning routine a treasury analyst runs today, done by the system before anyone logs in.
Collect prior-day statements
Statements arrive overnight from each bank as ISO 20022 camt.053 or BTRS files, through whichever channel that bank supports.
Normalize
Each bank's transaction codes map to one set of cash categories, and each account maps to its legal entity and currency.
Check opening balances
Yesterday's closing balance is compared with today's opening balance for every account, and any gap is flagged before anyone relies on the numbers.
Add intraday activity
Intraday reports add the wires and ACH settlements received so far today.
Add known flows
Payments released from the treasury system, maturing deposits and scheduled debt service are added even before the bank reports them.
Publish the position
Cash by entity, bank and currency goes to the treasury team, with funding and sweep suggestions for accounts above or below their target.
Bank connectivity
Which bank files does a treasury system send and receive?
The bank connectivity table we start every treasury build with. Each bank implements these standards its own way, so we test files with every bank before go-live.
| Message or file | Standard | What the treasury system does with it | Common failure point |
|---|---|---|---|
| Prior-day statement | ISO 20022 camt.053, or BTRS (formerly BAI2) | Builds the opening cash position and feeds bank reconciliation | Bank-specific transaction codes mapped to the wrong cash category |
| Intraday report | ISO 20022 camt.052, or BTRS intraday | Updates the position with receipts and debits posted so far today | Reports that repeat earlier entries, so receipts are counted twice |
| Debit or credit notification | ISO 20022 camt.054 | Matches single receipts to open receivables | Remittance detail cut short by the bank, leaving receipts unmatched |
| Payment initiation | ISO 20022 pain.001 | Sends approved supplier, payroll funding and intercompany payments to the bank | File rejected for a field the bank's own implementation guide requires |
| Payment status report | ISO 20022 pain.002 | Marks each payment accepted, pending or rejected and alerts the team | Rejections that arrive hours later and nobody reads |
| ACH batch | Nacha file format | Sends domestic ACH credits and debits, such as supplier payments and collections | Wrong company ID or Standard Entry Class code for the payment type |
File layouts differ by bank even under the same standard. We keep one versioned mapping per bank, so one bank's format change does not break the others.
Channels
How does the treasury system connect to each bank?
Most treasury teams need more than one channel, because each bank supports different ones.
Host-to-host SFTP
- Scheduled statement files from each bank
- Payment files pushed to the bank's server
- PGP encryption and signing
- Key rotation planned per bank
Swift
- One channel to many banks
- FileAct for files, messages for single payments
- Own connection or a service bureau
- Onboarding per bank relationship
Portal upload fallback
- For small banks with no file channel
- Files generated by the system
- Upload by a named user, logged
Cash forecasting
How does cash forecasting work?
A cash forecast built from the systems that already know about future cash, instead of a spreadsheet updated by hand. Each source is its own category, so variance shows where the forecast went wrong.
Payables
- Approved invoices by due date from the ERP
- Payment runs already scheduled
- Open purchase orders for a longer view
Receivables
- Open invoices by expected payment date
- Expected dates learned from each customer's past receipts
- Collections in progress
Payroll and tax
- Pay dates and funding amounts from payroll
- Tax payment dates by entity
Debt and investments
- Interest and principal schedules
- Maturing deposits and money market balances
- Credit facility draws and repayments
Intercompany
- Planned funding between entities
- Netting cycles, where you run them
Variance
- Forecast against actual cash each day
- Variance by category and entity
- The categories that miss most are reviewed first
Payment controls
Which controls stop a wrong payment before release?
Treasury payments are large and hard to recall. Each control runs before a file reaches the bank, and the system records who passed it.
01
Dual approval
Example: A supplier payment created by an analyst
Approach: A second person with approval rights releases it. The creator can never approve their own payment, and limits are set per user and payment type.
02
Segregation of duties
Example: One user can edit a bank account and also release payments to it
Approach: Roles separate bank account maintenance, payment creation and release, and a report lists any user holding conflicting rights.
03
Sanctions screening
Example: A cross-border payment to a new beneficiary
Approach: Beneficiary names, banks and countries are screened against the sanctions lists you use before release. A possible match holds the payment for review.
04
Bank detail changes
Example: A request to change a supplier's account number
Approach: The change needs a second approver and a call-back to a known contact, and the first payment to the new account is held for review.
05
File integrity
Example: A payment file altered after approval
Approach: Approved files are hashed and signed, so any change after approval stops the transmission.
What do we build into treasury management software?
Modules we scope one at a time, starting with the banks that hold most of your cash.
Bank connectivity layer
API, host-to-host and Swift connectors with one mapping per bank, and alerts for statements that did not arrive.
Cash position
Daily and intraday cash by entity, bank, account and currency, from statements and known flows.
Cash forecasting
Forecasts by category and horizon from payables, receivables, payroll and debt schedules, with variance tracking.
Payment hub
One place to create, approve and send supplier, payroll funding, tax and intercompany payments in each bank's format.
Payment controls
Dual approval, user limits, segregation of duties, sanctions screening and signed files.
Bank account management
Every account with its bank, entity, purpose, signers and status, and the history of each change.
Bank reconciliation
Statement lines matched to ledger entries, with unmatched items routed to an owner.
ERP and ledger sync
Bank fees, interest and released payments posted to the general ledger as journal entries.
Who it is for
Who do we build treasury software for?
Companies whose cash sits in more banks and entities than a spreadsheet can keep up with.
Multi-entity groups
Groups with subsidiaries in several countries and currencies that need one cash position every morning.
Teams outgrowing bank portals
Finance teams that log in to each bank portal daily to copy balances and upload payment files.
Payment-heavy businesses
Distributors, marketplaces and payroll providers that send large volumes of outgoing payments.
Shared service centers
Central teams that pay and collect on behalf of many business units.
Standards
Which standards does treasury software work with?
ISO 20022 camtISO 20022 painX9.121 BTRSNachaSwift31 CFR Part 501
Facts and sources
Facts behind treasury management software
The bank reporting standard, payment rules and sanctions regulation behind the connectivity table and payment controls, each linked to its primary source.
X9.121-2016, the Balance and Transaction Reporting Standard (BTRS) Version 3, gives banks and corporations a modernized format for reporting balances and transactions across banking relationships. Accredited Standards Committee X9 lists BTRS as the standard formerly known as BAI2.
Source: X9.121 BTRS (Accredited Standards Committee X9)The Federal Reserve's Fedwire Funds Service has migrated to ISO 20022, so its funds message formats now align with those used by other global high-value payment systems.
Source: Fedwire Funds Service ISO 20022 Implementation Center (Federal Reserve Financial Services)Nacha Operating Rules amendments effective June 19, 2026 require every non-consumer Originator, Third-Party Service Provider and Third-Party Sender not covered by the first phase to establish and implement risk-based processes and procedures reasonably intended to identify ACH entries initiated due to fraud, and to review them at least annually.
Source: Nacha, Risk Management Topics: Fraud Monitoring Phase 2Any U.S. person, including a financial institution, that rejects a transaction because processing it would violate OFAC regulations must report the rejected transaction to OFAC within 10 business days, with a copy of any related payment instructions or invoice.
Source: 31 CFR 501.604 (eCFR)
Scope and cost
What drives the cost of treasury software?
We price treasury builds on the scoping call, never from a rate card. These are the drivers that move the scope.
Banks and channels
How many banks you connect, and whether each offers APIs, host-to-host files or only Swift.
File formats per bank
Each bank's version of camt, pain, BTRS and Nacha files, and how far it strays from the standard.
Entities and currencies
Legal entities, countries and currencies in the cash position and the forecast.
Payment types
Wires, ACH, cross-border, payroll funding and intercompany payments, each with its own approval rules.
Forecast sources
The ERP, payroll and debt systems the forecast reads from.
Controls and audit
Approval matrices, sanctions screening and the reports your auditors ask for.
Engagement
How does a treasury software engagement run?
Bank onboarding needs the most coordination, so it starts first.
1.
Scoping call
We list your banks, accounts, entities and payment types, and walk through how the team builds the cash position today.
Scope2.
Bank connectivity and cash position
Statements from your main banks flow into a daily cash position, checked against the figures the team reports by hand.
Build3.
Payments, forecasting and more banks
The payment hub with approvals, the forecast and the remaining banks, with support after launch.
ScaleFrequently Asked Questions
Cash management software covers the daily cash position and the short-term forecast. Treasury management software adds payments, bank account administration, debt and investment tracking and the controls around them. Many companies start with cash visibility, and we design it so payments can be added later without a rebuild.
Yes. Most corporate banks offer host-to-host file transfer over SFTP, and many connect through Swift. For a small bank with no file channel, the system generates the file for a named user to upload and records each upload.
You can keep BTRS where a bank sends it. The system maps camt.053, camt.052 and BTRS into one transaction model, so the cash position does not depend on which format each bank uses. New bank connections usually start on ISO 20022.
Beneficiary names, banks and countries are checked against the sanctions lists you use before a payment is released. A possible match holds the payment for a reviewer, and the decision and its reason are stored with the payment.
Not usually. The ERP still decides which invoices to pay. The treasury system receives the approved payment run, applies treasury controls, formats a file for each bank and sends payment status back to the ERP.
Yes. Payables, receivables and open purchase orders come from the ERP, pay dates and funding amounts from payroll, and loan schedules from your debt records. Each source is a forecast category, so variance shows which source needs attention.
That work sits on our payment gateway integration services page. Treasury software handles a company's own bank accounts and the payments it sends.