SOC 1 by industry
Fintech and payments: proving that the ledger matches the money.
Merchants and platforms book revenue, receivables and cash from the balances you report. When their auditors ask how they know those balances are right, the answer is your reconciliations and the controls around them. This page walks the money from onboarding to the ledger and shows what a SOC 1 is expected to prove at each step.
Back to SOC 2 services01 · Money path
Following a payment from onboarding to the client's ledger
Five steps, each with something a client's auditor cares about.
Onboarding and account set-up
The merchant or account is created and its terms recorded.
- What happens
- Records pricing, settlement account and payout schedule
- Links the account to the right ledger entity
- You get
- An account master the ledger relies on
- Good practice
- Terms changed only with approval and a second check
- Watch for
- Payout bank details editable by support staff
Authorisation and capture
A transaction is approved and captured into your records.
- What happens
- Writes each captured transaction to the ledger once
- Applies the correct currency and amount
- You get
- A complete transaction population
- Good practice
- Interface checks that count what was sent and what was booked
- Watch for
- Captures that never reach the ledger after a retry
Settlement
Funds move between networks, acquiring banks and you.
- What happens
- Matches settlement files to captured transactions
- Records amounts due to and from each party
- You get
- Settlement balances per merchant and per bank
- Good practice
- Daily matching with ageing of unmatched items
- Watch for
- Settlement files loaded without control totals
Reconciliation
The ledger is agreed to bank statements and network reports.
- What happens
- Agrees cash, clearing and suspense accounts
- Escalates breaks by age and size
- You get
- Evidence that ledger balances equal real money
- Good practice
- Reviewed and signed by someone who did not prepare it
- Watch for
- Breaks parked in suspense with no owner
Fees, refunds and chargebacks
Charges and reversals are calculated and posted.
- What happens
- Applies contracted fees
- Posts refunds and disputes against the original transaction
- You get
- Net amounts paid out to clients
- Good practice
- Fee logic changes tested and approved
- Watch for
- Manual credits with no approval
02 · Objectives
Control objectives that fit a payments business
Written around completeness, accuracy and cut-off of money movement.
| Objective area | What it should give reasonable assurance of | What a service auditor typically samples |
|---|---|---|
| Account set-up | Client terms and payout details are set up and changed with approval | Changes to pricing and bank details, with their approvals |
| Transaction capture | Captured transactions are recorded once, completely and accurately | Interface reconciliations between gateway and ledger |
| Settlement | Settlement amounts are matched and recorded in the right period | Daily matching reports and their sign-off |
| Reconciliation | Ledger balances are reconciled to bank and network records and breaks are resolved | Month-end reconciliations, ageing and review evidence |
| Fees and reversals | Fees, refunds and chargebacks are calculated per contract and approved | Fee changes, manual credits, a sample of chargebacks |
| Supporting IT | Changes to payment logic and access to the ledger are controlled | Change tickets, access reviews, privileged user lists |
Keep objectives about your processing. Whether a merchant's revenue is recognised correctly is the merchant's question; whether the amounts you report to it are complete and accurate is yours.
03 · PCI DSS and SOC 2
Where PCI DSS and SOC 2 fit beside it
Three different questions, often asked of the same company.
SOC 1
Are the numbers right?
- Controls relevant to clients' financial reporting
- Read by clients' auditors
- Issued by a licensed CPA firm
PCI DSS
Is card data protected?
- Security of cardholder data and the environment that holds it
- Read by acquirers and card brands
- Assessed against the PCI Security Standards Council requirements
SOC 2
Is the system secure and reliable?
- Trust services criteria such as security and availability
- Read by customers' risk and security teams
- Issued by a licensed CPA firm
A PCI DSS assessment says nothing about whether settlement balances are correct. A SOC 1 says little about how card numbers are stored. Neither replaces the other.
04 · Banks and processors
Banks, processors and networks as subservice organizations
Most of your money path runs on someone else's system.
Sponsor banks, acquiring processors, card networks and payout rails all touch the numbers. In a SOC 1 they are subservice organizations when their controls matter to your objectives. Most fintechs present them by the carve-out method: the description names them and states what controls you assume they run.
- Settlement files from a processor are complete and accurate when delivered.
- Bank statements reflect all movements on the account in the right period.
- The partner bank restricts who can initiate payments from client money accounts.
- Network dispute files include every chargeback raised against a client.
These assumptions become complementary subservice organization controls. The description should also say how you monitor each partner, for example by reviewing its own SOC 1 or by your own reconciliation of its output.
05 · Traps
Payments-specific traps
The weak points are usually suspense accounts and manual fixes.
- Suspense accounts nobody owns. Unmatched items sit for months. A reconciliation that is signed while breaks keep ageing does not achieve its objective.
- Reconciling the ledger to itself. Comparing two internal reports is not a reconciliation. The other side has to be a bank or network record.
- Fee changes pushed as config. Pricing changed in a settings screen escapes change management, yet it changes every client's payout.
- Refunds outside the normal flow. Goodwill credits keyed by support staff, with no approval or link to the original payment.
- Partner reports not reviewed. Carving out a bank but never reading its report or checking its output leaves the monitoring claim empty.
06 · Scenario
An illustrative settlement break
A one-day mismatch and the evidence that closed it.
Illustrative: a missing settlement batch
A processor delivers a settlement file one batch short after a system change on its side. The daily match flags the difference, and an analyst records it as a break with an owner and a due date. Two days later the processor resends the batch, the match clears and the reviewer signs the exception log. In fieldwork the service auditor picks that day. The evidence shows detection, follow-up and resolution, so the control operated as described even though the processor's file was wrong.
Sources: AICPA SSAE No. 18, AT-C section 320, as amended; AICPA Guide, SOC 1 Reporting on an Examination of Controls at a Service Organization Relevant to User Entities' Internal Control Over Financial Reporting; PCI Security Standards Council, Payment Card Industry Data Security Standard (PCI DSS). Objectives, partners and the scenario are illustrative.
Questions fintechs ask about SOC 1
We are PCI DSS compliant. Does that count toward a SOC 1?
Some IT controls overlap; the objectives do not.
Access and change controls you built for PCI DSS can support a SOC 1, but the SOC 1 still needs objectives about recording, settling and reconciling money, which PCI DSS does not address.
Our partner bank has its own SOC 1. Do we still need one?
Yes, if your clients rely on your processing.
The bank's report covers the bank's controls. Your clients' balances come from your ledger and reconciliations, which only your report can cover.
Should the inclusive method be used for the processor?
Rarely in practice.
Inclusive presentation needs the processor to take part in your examination and give its own assertion. Most fintechs use carve-out and monitor the processor instead.
We are an Indian payment aggregator. Who asks for a SOC 1?
Usually clients with an external audit that relies on your balances.
Requests most often come from clients whose auditors, including those reporting under US rules, want evidence about controls outside the client. Local regulatory requirements are separate and are not met by a SOC report.
Trace your money path before fieldwork.
We map capture to reconciliation, write objectives for each step and test the controls on your partner feeds before you engage a CPA firm.