Sectors where a security finding is also a licensing problem

Payment businesses carry two security burdens at once: an attacker who wants to move money, and a scheme or supervisor who wants evidence that controls operate. An assessment that addresses only the first leaves the firm exposed to the second. We scope engagements for fintech and payment clients so that findings arrive framed against both.

PCI DSS scoping. The most expensive mistake in card environments is a cardholder data environment larger than anyone intended. Systems that store, process or transmit card data are obviously in scope; systems that can affect the security of those systems are in scope too, and that second category quietly absorbs shared identity providers, monitoring agents, jump hosts and CI runners. We trace where card data actually flows against where the documented flow says it goes, identify segmentation controls that are assumed rather than enforced, and test those controls rather than accepting a network diagram. Where tokenisation is used to reduce scope, we test whether the token can be exchanged back for a primary account number by a caller who should not be able to do so.

PSD2 and strong customer authentication. SCA implementations fail at the exemption boundary far more often than at the authentication step itself. We test whether low-value, recurring and trusted-beneficiary exemptions can be forced by a caller who is not entitled to them, whether the dynamic linking of amount and payee survives the full authorisation chain, and whether an authentication downgrade path remains reachable from a legacy client. Transaction risk analysis exemptions are reviewed for whether the fraud rate thresholds are actually measured or merely asserted.

Open banking APIs. Third-party provider integrations expose consent and account access to callers whose own security posture the firm does not control. Assessment covers consent lifecycle handling — creation, scope, expiry, revocation — and whether a revoked consent immediately stops data flow across every cached path. Certificate-bound access, client authentication and token binding are tested for whether the binding is enforced by the resource server or only by the authorisation server. Account information endpoints receive the same object-level authorisation testing as any other API, because a consent identifier is just another identifier that can be swapped.

Tokenisation and key handling. Where the firm operates its own token vault or encryption service, we review key hierarchy, rotation, access separation between the vault and the applications that call it, and whether an application compromise yields bulk detokenisation or only per-transaction access. Rate limits and monitoring on detokenisation volume are treated as controls, not conveniences.

Fraud and business logic. Refund replay, partial capture manipulation, currency conversion rounding, chargeback workflow abuse and limit counters that reset on a boundary rather than a rolling window are all tested explicitly. These findings rarely appear in tooling output and are frequently the highest-value items in the report.

Reporting is structured so the same evidence answers a scheme question, an internal audit question and a supervisory question without being rewritten three times.

Exchanges and custodians hold assets whose transfer is final. There is no chargeback, no clearing house to reverse an entry, and in most cases no realistic recovery once a withdrawal confirms. That single property reorders every security priority, and our assessments for this sector are built around it.

Wallet architecture. We review the split between hot, warm and cold tiers against the actual operational load rather than the policy document: how much value sits in the hot tier at peak, how often a manual cold movement is required, and whether the pressure of that frequency has produced an informal shortcut. Sweep logic, change address handling and the segregation between customer assets and firm treasury are reviewed for both correctness and accounting integrity.

Key management. For HSM deployments, the review covers key ceremony evidence, quorum configuration, separation between key custodians and platform operators, and whether the device policy genuinely constrains what the signing service may request. For MPC deployments, it covers share distribution across independent failure domains, the policy engine that authorises a signing round, share refresh procedures, and what happens when a share holder is unavailable. Recovery arrangements are assessed for whether they have been exercised — an untested backup scheme is a hypothesis, and several publicised custody failures have turned on exactly that point.

Withdrawal authorisation. The withdrawal path is tested as a chain: creation, validation, risk scoring, approval, signing, broadcast, confirmation. At each link we test whether the control can be bypassed by entering further along, whether limits are enforced server-side and atomically, whether an approval threshold can be satisfied by a single compromised operator, and whether address allowlisting survives a change window or an administrative override. Concurrency is tested actively: withdrawal requests that each pass a balance check before either debits have caused real losses at real platforms.

Exchange infrastructure. Matching engine and order management systems are assessed for authorisation on internal interfaces, market data integrity, and abuse of order types under conditions the engine was not designed for. Administrative tooling — the internal console that can adjust a balance, cancel an order or unlock an account — receives particular attention, because it usually has the greatest capability and the least testing.

Chain-specific behaviour. Deposit confirmation depth is reviewed per chain rather than as a single global value, with reorganisation handling, replay exposure across forked networks and non-standard token behaviour tested against the specific assets supported. Contracts with transfer fees, rebasing supply, blocklist functions or callback hooks that re-enter crediting logic are a recurring source of accounting drift.

Findings are reported against loss potential first and control framework second, because for this sector that is the order in which the board will read them.

Digital asset service providers face security review as part of authorisation, not only as an operational concern. Supervisors and their technical reviewers ask a narrower question than a general security assessment answers: can this firm safeguard client assets, evidence that its controls operate, and detect and report when they do not. An engagement scoped for a firm preparing or maintaining an authorisation is built to answer that question directly.

A pre-licensing security assessment, where a firm requests one, is scoped around the control areas an authorisation file has to evidence rather than around attack surface alone. The output is written so it can be submitted alongside an application: scope stated precisely, methodology named, findings scored, remediation dated and retested. We do not draft applications, advise on licensing strategy or act as an intermediary with any authority — those are separate functions, and mixing them would compromise the independence that makes the assessment worth submitting.

Custodial wallet infrastructure. Assessment covers the safeguarding boundary between client and firm assets, key generation and custody arrangements, quorum and approval design, recovery procedures and whether they have been exercised, and the reconciliation process that proves holdings match obligations. Where a firm relies on a third-party custodian, the review covers the integration and the firm's own controls over it rather than the custodian's internals.

KYC and AML integration security. Identity verification and screening pipelines handle sensitive personal data and produce decisions with regulatory weight. We assess transport and storage of verification artefacts, whether a screening result can be altered or bypassed after the fact, whether a failed check can be re-run until it passes without that being recorded, and whether the audit trail is complete enough to reconstruct why a customer was accepted.

Transaction monitoring systems. Monitoring is treated as a control that can fail silently. Review covers completeness of the event feed, whether any transaction path bypasses monitoring, tamper resistance of rules and thresholds, alert handling and closure integrity, and whether a privileged user can suppress an alert without leaving evidence.

Blockchain analytics integrations. Where third-party analytics inform risk decisions, we assess authentication and credential handling for the integration, what happens when the provider is unavailable — fail-open versus fail-closed is a design decision with regulatory consequences — and whether results are cached in a way that could return a stale risk classification.

Regulatory reporting infrastructure. Reporting systems are assessed for data integrity from source to submission, access control over report generation, retention and immutability of submitted records, and travel rule data handling including the security of counterparty exchange channels.

Where INLD has no direct experience of a specific authority's technical review process, we say so at scoping rather than after. The assessment is delivered against published standards, which is what makes it portable between jurisdictions.

A multi-tenant platform makes one architectural promise above all others: that a customer can only reach their own data. Every other control is secondary to that, and it is the control most likely to be undermined by ordinary feature work rather than by an attacker finding something exotic.

Tenant isolation. We test isolation at every layer it is claimed to exist: application, data access, storage, cache, search index, background jobs, exports and webhooks. The recurring pattern is an isolation model enforced consistently in the primary request path and inconsistently everywhere else — a report generator that queries without the tenant predicate, a cache key that omits the tenant identifier, an asynchronous job that runs with elevated credentials because that was simpler at the time. Where isolation is enforced by a shared query layer, we test whether any path bypasses it.

Role-based access control. Permission models grow by addition. We map the effective permission graph rather than reading role definitions, then test whether the implemented checks match the model: whether a role can grant itself capability it does not have, whether an invitation flow can escalate, whether administrative impersonation is logged and bounded, and whether permission changes take effect immediately or only after a cached session expires.

Secrets management. Assessment covers where application secrets, customer credentials and integration tokens live, how they reach running workloads, whether they appear in build logs, error reports or client bundles, and how rotation works in practice. Customer-supplied credentials — the API keys a tenant stores so the platform can integrate with their systems — are treated as the highest-sensitivity data on the platform, because a breach there propagates outward to every customer's own environment.

CI/CD pipeline security. The deployment pipeline is usually the most privileged system in the estate and the least assessed. Review covers who can trigger a deployment and with what approval, whether pipeline credentials are scoped per environment or shared, whether a pull request from a fork can execute with repository secrets, artefact integrity between build and deploy, and whether infrastructure changes can be made outside the pipeline without detection. Dependency and supply chain handling is reviewed alongside: lockfile enforcement, provenance of build images and how a compromised transitive dependency would be identified.

Cloud-native application security. Where the platform runs on orchestrated containers, we assess workload identity, namespace and network policy separation, admission control, secret mounting, and whether a compromised workload can reach the control plane or the metadata service. Findings are mapped to the tenant isolation promise wherever they affect it, so the report answers the question customers actually ask during their own vendor due diligence.