Passing a Bank or Partner Security Review: The Software List Auditors Ask For

Sooner or later, every money transfer operator receives a long questionnaire from a bank, a payout partner or a regulator asking how its technology is built, hosted and controlled. The operators who pass quickly are rarely the ones with the most sophisticated systems. They are the ones who can produce clear, current evidence on request.

A technology review can hold up a bank account, a payout corridor or a licence application for weeks, usually over the same questions: what software do you run, where is it hosted, who can access it, who changed what, and how do you release changes safely. One has become more common: can you give us a list of every software component in your platform?

This guide is for CTOs and compliance leads. It explains why these reviews happen, what reviewers typically ask for, what a software bill of materials (SBOM) is, and how to put together a review pack that answers most questions before they are asked. It ends with a worked scenario of a partner due-diligence questionnaire.

We use RemitSo as one example of a platform that supplies much of this evidence. RemitSo provides a downloadable software list in CycloneDX format, is certified to ISO 27001:2022 and ISO 9001:2015, and gives operators two-step sign-in, permission-based roles, logged sign-in sessions and kept decision records, releases tested on the operator's staging and hosting in a dedicated AWS account in the operator's region. What it does not do is answer the questionnaire for you. Your own policies, your own staff controls, your own risk assessment and your relationship with the reviewer remain your responsibility.

A money transfer operator sits in the middle of a chain. Banks hold its customer funds and settlement accounts. Payout partners deliver money on its instructions. Regulators hold it responsible for protecting customer data and preventing financial crime. Each of these parties takes on risk when it connects to you, and each is itself reviewed on how it manages third parties.

• Banks want to know that the operator's systems will not become a route for fraud, data loss or money laundering that ends up on the bank's books.
• Payout partners want assurance that instructions arriving over their API are genuine, authorised and complete, and that a compromise at the operator will not lead to unauthorised payouts.
• Regulators want evidence that the operator understands and controls its operational and outsourcing risk, including the risk that sits with its technology supplier.

Reviewers are assessing control, not features: that you know what you run, access is limited, changes are governed and you can reconstruct what happened.

Questionnaires vary in length and style, but most cover the same six areas.

1. Software inventory

What applications, libraries and services make up the platform, which versions are in use and under what licences. Increasingly this is requested as a software bill of materials rather than a description.

2. Hosting and data location

Where the platform runs, who owns the hosting account, in which region customer data is stored, and who at the vendor can reach it.

3. Access control

How staff sign in, whether two-step sign-in is enforced, how roles are defined, how access is granted and removed, and whether staff only see what their job requires.

4. Audit trail

Whether the system records who changed what and when, what the previous value was, and whether those records can be altered.

5. Change management

How new releases are tested, who approves them, whether there is a separate test environment and how a faulty change would be rolled back or contained.

6. Certifications and assurance

Which recognised standards apply, such as ISO 27001 for information security, and the scope of each certificate.

On the audit trail question, be precise. Reviewers are better served by a list of the specific records you keep, and what each shows, than by a general claim that "everything is logged". A claim they cannot test invites a follow-up; a named record with a sample extract usually closes the question.

Many also ask about business continuity, incident response, data retention, penetration testing and staff vetting. Being clear which of these belong to the vendor, to you or to both is half the work.

A software bill of materials is a structured list of the components that make up a piece of software: the open-source and third-party libraries, their versions, where they came from and the licences they are distributed under. It is the software equivalent of an ingredients list.

Reviewers ask for one for two practical reasons.

• Vulnerability exposure: when a serious flaw is announced in a widely used library, the first question is whether you use it. An SBOM lets you, your vendor and your reviewer answer that by searching a file rather than by asking engineers.
• Licence risk: some open-source licences carry obligations. An SBOM shows which licences are present so that legal and procurement teams can assess them.

There are two widely used SBOM formats. CycloneDX, maintained under the OWASP Foundation, was designed with security use cases in mind and is commonly produced as JSON or XML. SPDX, maintained under the Linux Foundation, grew out of licence compliance work. Both are machine-readable and accepted by most tools that scan for known vulnerabilities.

A typical CycloneDX entry records a component's name, version, supplier, package identifier and licence, which a reviewer's tooling can check against public vulnerability databases.

The fastest way through a review is to have a standing pack of evidence, refreshed on a schedule, that answers the common questions. The table below lists what to include, who usually supplies it when you run on a vendor platform, and what reviewers look for.

Keep the pack in one controlled location, assign an owner, and record the date each item was last refreshed. An SBOM from six months ago tells a reviewer that you are not watching it.

The following scenario is illustrative. The numbers are examples, not benchmarks.

An operator licensed in the United Kingdom wants to add a new payout partner for a corridor into South Asia. The partner sends a technology and information security questionnaire with 110 questions and asks for a response within 15 working days. The operator runs on a vendor platform and has a CTO and a compliance lead but no dedicated security team.

Day 1: triage

The CTO sorts the questions into three groups:

• Platform questions (around 60): software inventory, hosting, encryption, sign-in, roles, audit trail, release process, certifications.
• Operator questions (around 35): policies, staff vetting, training, incident response, business continuity, data retention.
• Shared questions (around 15): vendor management, access to production data, how incidents involving the platform are escalated.

Days 2 to 5: evidence from the platform

From the existing review pack, the CTO attaches the current SBOM in CycloneDX format, the ISO 27001:2022 and ISO 9001:2015 certificates, a description of the dedicated AWS account and its region, screenshots of the two-step sign-in and role configuration, an extract of staff login sessions filtered to show any sign-in where two-step sign-in was not completed, a sample of screening decisions from sanction lookup, the infrastructure architecture and environment overview from the console, and the release notes showing that releases go to staging first. Questions the pack does not answer, such as specific encryption settings, go to the vendor as a single consolidated list rather than one at a time.

Days 3 to 10: operator evidence

The compliance lead supplies the information security policy, the staff training records with sign-off, the incident response procedure and the business continuity plan. Two gaps appear: there is no written access review procedure, and the leaver process does not mention removing admin access. Both are written up and approved during the review, and the partner is told so plainly.

Day 12: follow-up questions

The partner's security analyst scans the SBOM and asks about two components with known vulnerabilities. Because the SBOM is current and machine-readable, the vendor can confirm within a day whether those components are reachable in the platform and when they are scheduled for update. Without an SBOM, the same question would have started a much longer exchange.

Day 14: submission

The operator returns the questionnaire with every answer cross-referenced to a document in the pack. The partner accepts it with one condition: evidence of the first quarterly access review within three months.

Most of the time saved came from platform evidence already being available. The real gaps were in the operator's own procedures.

• Scope of certificates: a supplier's ISO 27001 certificate covers the supplier's own information security management system. Say so clearly, and do not present it as a certificate of your own business.
• Dates: every document has a date and, where relevant, a version. Replace anything stale.
• Consistency: your answers about hosting region, data retention and access match what you told your regulator and your bank.
• Named owners: each control has a named person responsible for it, not just a team.
• Honest gaps: where a control is being put in place, say so and give a date. Reviewers generally respond better to a plan than to an answer that later proves untrue.
• Confidentiality: share the SBOM, architecture details and audit extracts under a non-disclosure agreement, and keep a record of what was sent to whom.

RemitSo supplies much of the platform evidence in a review pack. Each item below is listed with the benefit it gives your review. The full list sits on the admin features page.

• Software Bill of Materials and Infrastructure Architecture pages: the software list downloads in CycloneDX format, a file a reviewer's tools can scan, and the architecture page answers the hosting question from the console rather than a diagram drawn for the occasion.
• ISO 27001:2022 and ISO 9001:2015 certified: recognised evidence of the supplier's information security and quality management to sit alongside your own policies.
• Dedicated AWS account in your region: billed by AWS to your own card, which gives you a straightforward answer on data location and account ownership. Hosting terms are on the white label pricing page.
• Two-step sign-in for staff, rate-limited codes: authenticator app or email code, and sign-in, sign-up and verification codes are rate-limited in the apps and console, so you can show that access is protected beyond a password.
• Roles built from 89 permissions: each described in plain language, so you can show a reviewer exactly what a role can and cannot do; even screens such as Scout and the Compliance Dashboard are granted part by part, which supports least-privilege answers and access reviews.
• Login sessions: every staff and customer sign-in logged with time, IP address, location, client app, operating system and whether two-step sign-in was completed, filterable to the ones where it was not.
• A searchable, plain-language audit log and named decision records: the audit log answers who changed what, and when, and can be filtered to the sample a reviewer asks for; alongside it sit rate history, screening decisions, KYC approvals and rejections with labels, and AML rules history of changes, so each control question can be answered with a specific extract rather than a general claim.
• Controlled AI assistant access (an optional add-on): staff can connect an AI assistant with a personal access token; it sees only what that person can see, never receives personal data, and every question it asks is recorded, which answers a question reviewers are starting to ask.
• Accounting entries never edited, payouts locked once approved: demonstrates that financial records and payout instructions cannot be altered quietly.
• Outbound API and webhook logs: every call to a payment or identity provider, and every partner request, is on the record with status code and error, keys masked, and every incoming message saved before processing, which gives payout partners traceability.
• Third-party integrations page: shows which providers are set up and which are missing something, a quick way to answer "which third parties process data on your behalf?".
• Releases tested on your staging first: supports your change management answer; changes are published in the release notes.
• Source code option: for operators or regulators who require it, the source code pricing page sets out the terms.

Your team still owns your policies, risk assessment, staff vetting and training, access reviews, incident response and the relationship with each reviewer. If you are preparing for a bank or partner review and want to see the evidence available, you can book a demo.