A BSP-supervised institution can use the cloud — the Bangko Sentral has been clear about that for years. What it cannot do is treat the cloud as a place where its obligations stop. BSP’s technology- and cloud-outsourcing framework sets the posture a supervised institution’s cloud setup has to demonstrate, and that posture is the foundation everything else, including AFASA-era fraud monitoring, has to sit on.
BSP Circular 982 and the wider technology-risk and outsourcing framework established the principle that outsourcing an operation does not outsource the responsibility for it. When a bank or e-money issuer runs its systems on a cloud provider, the institution remains accountable to the BSP for the security, continuity, and auditability of those systems. The notification and risk-management expectations around technology outsourcing exist to make that accountability concrete. For an engineering team, this translates into a set of properties the cloud setup has to actually have — not a checkbox the provider ticks on your behalf.
What the cloud setup has to demonstrate
Data residency you can prove
The institution has to know — and be able to show the supervisor — where its data physically lives, and to keep that consistent with its risk assessment and any commitments it has made. “It’s in the cloud” is not an answer; “it is in this region, in this provider, under this configuration, and here is how we enforce that” is. The engineering requirement is a deployment whose data residency is a controlled, demonstrable property, not an emergent default of whichever region a service spun up in.
An audit trail the supervisor can follow
The framework assumes the institution can reconstruct what happened in its systems — who accessed what, what changed, when, and on whose authority. A cloud setup that cannot produce that trail leaves the institution unable to answer the BSP’s questions during an examination or an incident. The audit trail is not optional infrastructure; it is the thing that turns a control into evidence, which is the same requirement every other Philippine regime imposes.
Encryption at rest, and the keys you control
Encryption at rest is table stakes; the part that matters is who controls the keys. A setup where the institution holds and manages its own encryption keys is in a materially stronger position — with the supervisor and in a breach — than one that hands key management wholesale to the provider. The architecture decision is to keep cryptographic control on the institution’s side of the line.
Continuity and exit
The outsourcing framework cares about what happens when things go wrong: business continuity if the provider has an outage, and a viable exit if the relationship ends. A cloud setup that cannot be recovered or migrated — because the institution does not hold its own infrastructure-as-code, its own data, and its own keys — is a concentration risk the supervisor expects to see managed. Owning your deployment is not just a cost decision; under this framework it is a resilience requirement.
Where institutions get the posture wrong
The recurring mistake is assuming that a compliant cloud provider produces a compliant institution. The major providers offer the building blocks — regional data centres, encryption services, logging, compliance attestations — but assembling them into a configuration that satisfies the BSP posture, and being able to demonstrate it, is the institution’s work. A bank can run on a certified provider and still fail an examination because its ownconfiguration cannot prove residency, cannot reconstruct access, or cannot survive the provider’s outage. The certification is necessary and not sufficient.
The AFASA overlay
For a supervised institution, the cloud posture is not the end of the story — it is the foundation the real-time controls sit on. The AFASA fraud-monitoring obligations assume an environment that already satisfies residency, audit, and encryption: the behavioural scoring, the device signals, the screening, and the tamper-evident decision log all run inside the cloud setup this framework governs. Build the posture first and the monitoring layer has somewhere solid to stand; bolt the monitoring onto a cloud setup that cannot prove its own controls and you have two compliance gaps stacked on each other.
This is one reason we are direct that Orkids routes top-tier banks through certified channel partners: at that scale the cloud and outsourcing relationship is a vendor decision with years of supervisory history behind it. Where this note is useful is for the smaller supervised institution — the digital bank, the e-money issuer, the rural bank — building or rebuilding its own setup, where owning the deployment, the data, and the keys is both the cheaper path and the more defensible one.
What this means for your institution
Four questions tell you where you stand. Can you demonstrate, not just assert, where your data resides? Can you reconstruct who accessed what, for any period, to the supervisor’s satisfaction? Do you control your own encryption keys? And could you recover or exit your cloud setup if the provider failed or the relationship ended? If any answer is “the provider handles that,” the posture is thinner than it looks. These are architecture decisions, they are cheaper to make than to retrofit, and they are the foundation the rest of your regulatory obligations depend on. If you want a read on your current setup against the framework, that is an engineering conversation we are glad to have.