Compliance at the API Layer: Moving Beyond Conditional Logic in Application Code

Payment compliance in Singapore has a specific character that teams sometimes underestimate until they have encountered it in a regulatory review. MAS does not operate through quarterly summaries or annual audits of completed transactions. It operates through ongoing supervisory requirements that affect how payment services are licensed, what records must be maintained, and what controls must be in place at the time a transaction is processed, not after the fact.

For platform teams building on payment rails, this creates a practical engineering problem: compliance rules need to be applied at transaction time, and they change as MAS updates its requirements. If those rules live in your application code, every regulatory update requires an engineering deployment. That coupling is manageable when updates are infrequent. It becomes a liability when MAS issues updated guidance, as it has done at intervals that have accelerated over the past few years for matters relating to cross-border payments and digital payment token services.

Where Payment Compliance Rules Live Today on Most Platforms

The typical pattern on a growing platform looks like this. The first payment integration has no explicit compliance layer. The developer integrates the provider SDK, handles success and failure responses, and ships it. As the platform grows and acquires a standard payment institution or major payment institution license under the Payment Services Act, a compliance consultant or in-house legal counsel produces a document listing required controls. Engineering translates this document into conditional logic in the application code.

That conditional logic might look like this: if the transaction amount exceeds a threshold, require additional customer verification. If the counterparty is in a jurisdiction on an exclusion list, reject the transaction. If the transaction type is a digital payment token service, apply additional screening. Each of these conditions is encoded as an if-statement somewhere in the routing or payment initiation path.

The problem is not that these conditions exist. The problem is where they live and how they are maintained. Conditions embedded in application code accumulate technical debt of a specific kind: compliance debt. When MAS issues MAS Notice PSN01 updates affecting stored value facility controls, or when its guidance on cross-border wire transfers changes, someone has to identify which code paths are affected, update them, test them, and deploy. In a small engineering team, that process takes time that may not be available immediately, and the gap between a regulatory update and code deployment is itself a compliance exposure.

The Payment Services Act Compliance Surface

It is worth being specific about what the Payment Services Act compliance surface looks like for a Singapore platform, because the scope is often wider than teams expect when they first encounter it.

Section 6 of the Payment Services Act requires licensing for carrying on a payment service business. The license type (standard payment institution, major payment institution) determines the regulatory obligations. A major payment institution license triggers a range of requirements including: AML/CFT controls under the MAS Notice on Prevention of Money Laundering (PSN01 and PSN02 for different service types), customer due diligence obligations, transaction monitoring and suspicious transaction reporting, and record-keeping for prescribed periods.

For each of these requirements, there is an engineering implementation: transaction monitoring rules that flag patterns for review, CDD data collection requirements at onboarding, record retention that affects your data model and storage policy. The point is that each of these has ongoing maintenance cost, and when the underlying regulatory requirement changes, the implementation needs to change in step.

We are not lawyers and this is not legal advice. For specific compliance obligations under your license type, you need qualified legal counsel familiar with the Payment Services Act. What we can address is the engineering architecture question of where compliance logic should live to minimize the deployment coupling problem.

The Case for the API Layer

The API layer is the correct place for payment compliance rules for the same reason it is the correct place for routing rules: it is the point where all payment requests pass before any provider interaction occurs. This gives it a complete view of every transaction parameter: amount, currency, corridor, transaction type, counterparty, and any customer context that is passed with the request.

When compliance rules run at the API layer, your application does not need to know which specific rules apply to a given transaction. It submits the payment request and receives back either a routing decision (the transaction is compliant and here is where it will be sent) or a compliance hold with a reason code (the transaction requires additional review for reason X). Your application handles these as response states. It does not need to implement the rules that produced them.

This decoupling has a direct consequence for regulatory updates. When MAS updates the transaction screening requirements for cross-border remittances, the change is made in the compliance rule set at the API layer. Your application code does not change. You do not deploy to update compliance behavior. The rule update is applied immediately for all new transactions, and the audit log records the version of rules in effect at the time of each transaction decision.

What the Compliance Layer Needs to Record

An audit trail is not optional for MAS-regulated payment services. Section 35 of the Payment Services Act and the related notices specify record-keeping obligations. For transactions that involve customer due diligence, transaction monitoring, or suspicious transaction reporting, you need records that can demonstrate that your controls were applied correctly at the time of the transaction.

If compliance rules live in your application code, your audit trail may be limited to the transaction outcome. You know the transaction was processed or rejected, but the record of which compliance rule applied, at which version, and what the input parameters were may not be reliably captured. In a regulatory review, this is a gap.

A compliance layer at the API level produces a compliance decision record for every transaction: input parameters, rule set version, individual rule outcomes, and final decision. This record is the audit trail. It is produced automatically, it is consistent, and it is available for export in the format regulators are likely to request.

In Checker's implementation, every payment that passes through the compliance check produces a compliance record linked to the payment's internal ID. If a transaction is reviewed later, the compliance record shows exactly what rules were applied, in what version, and what the outcome was. This is not a report generated after the fact; it is a record created at transaction time.

The Consistency Argument

One argument for embedding compliance in application code is that it is closer to the business context: the application knows whether a customer is a corporate or individual, whether they have completed enhanced due diligence, and what their transaction history looks like. Moving compliance to an external layer seems to lose this context.

This is a real concern, but it points to an API design question rather than an architecture limitation. The correct design is that your application passes the relevant compliance context with the payment request. Customer type, CDD status, risk rating, and any other parameters that compliance rules need are included in the routing call. The compliance layer uses this context to evaluate rules. It does not need to query your customer database independently; your application provides the context it has.

This is actually a better design than embedding compliance in application code, because it makes the compliance inputs explicit. When compliance logic is embedded in your application, the parameters it uses may be implicit: it reads from objects in scope, or it queries the database as a side effect. Explicit context passing means that the compliance record can capture exactly what inputs the rules were evaluated against, which is the foundation of a defensible audit trail.

Implementation Realism

We want to be honest about what extracting compliance to the API layer costs. It requires that your payment routing call includes sufficient context about each transaction and customer. Platforms that have been accumulating compliance logic in application code for two or three years face the same extraction challenge as routing logic. The compliance context is scattered across the application, and formalizing it into a structured API call requires an audit of what your rules actually consume.

For teams building new payment infrastructure, starting with the API layer design is the cleanest path. For teams with existing embedded compliance logic, the extraction can be staged: identify the compliance rules that change most frequently (typically, transaction monitoring thresholds and corridor exclusions), extract those first, and leave stable rules in application code during the transition period. This gets you the most benefit from the decoupling with the least immediate disruption.

The goal is not a perfect migration done all at once. It is reducing the compliance-to-deployment coupling for the rules that change most often, so that regulatory updates do not require a deploy review cycle every time MAS issues updated guidance on a Friday afternoon.