Bank of Thailand API Payload Encryption Rules

For years, “encrypt data in transit” meant one thing: put HTTPS on it. TLS terminated at the load balancer, the payload flowed through the internal network in cleartext, and everyone called it encrypted. The Bank of Thailand has been steadily closing that gap, and the direction is clear: for sensitive financial data, transport encryption alone is no longer enough.

The difference between transport and payload encryption #

TLS protects data between two points on a wire. It does not protect the data inside the application. The moment TLS terminates at the reverse proxy, the API gateway, or the load balancer, the payload is decrypted and handed to the backend in plaintext.

That plaintext then travels through, and sits in, places you would rather it did not:

• Logs: an over-eager gateway logging request bodies captures full PANs and account numbers.
• Service mesh and internal hops: east-west traffic between microservices is frequently unencrypted on the assumption the network is “trusted.”
• Memory and caches: in-memory request objects, debug dumps, and APM traces can all retain the decrypted payload.
• Observability pipelines: metrics and traces that forward spans across teams and third parties.

Application-layer payload encryption closes this gap by encrypting the message itself, so it stays protected regardless of how many hops it crosses or what the infrastructure does with it.

What the standard says to use #

The mechanics of payload encryption are standardised and well understood:

• JSON Web Encryption (JWE) (RFC 7516): the de facto standard for encrypting structured API payloads, wrapping a symmetric data key with an asymmetric recipient key.
• AES-256-GCM: the authenticated encryption workhorse for the payload body, providing both confidentiality and integrity.
• RSA-OAEP or ECDH: the key-encapsulation layer that protects the symmetric key in transit and at rest.

The pattern is the same one TLS itself uses: a fast symmetric cipher for the bulk data, wrapped by an asymmetric key exchange, but applied at the message level so it survives beyond the TLS session.

Why BOT is pushing this now #

The regulator’s reasoning is not exotic. Financial APIs now form the connective tissue of the whole Thai payments ecosystem: banks, PSPs, fintechs, merchants. A single gateway misconfiguration should not expose account data to anyone with log access. Payload encryption is a defence-in-depth measure: it assumes the transport will be inspected, logged, or compromised at some point, and it makes sure the sensitive data is not readable when that happens.

This aligns with the same principle behind PCI DSS’s requirement to protect stored cardholder data: the moment you stop trusting any single hop, you stop treating “the network is safe” as your only control.

Practical implications for your engineering team #

Adopting payload encryption is not a config toggle. It means:

• Key management becomes a first-class concern. You need rotation, separation between signing and encryption keys, and protected key storage.
• Gateway and logging changes: everything that reads or logs request bodies must be re-evaluated, because the body is no longer readable by middleware.
• Contract changes: downstream consumers must be able to decrypt, which means key distribution and versioning across every party in the chain.
• Testing: observability must move from “dump the payload” to “authenticate and authorise, then decrypt only where necessary.”

None of this is optional if you operate in the BOT’s orbit. It is a shift from “encrypt the pipe” to “protect the message.”

Our Regulatory Compliance alignment maps BOT guidance to concrete engineering requirements, and our API & Application Security Review verifies how your payloads are actually protected end to end.