How banks govern API surfaces with Apinizer

The audit, encryption, and three-tier permission model that the regulators actually want — built into the platform, not bolted on as middleware.

Feb 4, 2026 · 2 min read · Ayşe Yıldız, Customer Engineering · Industry

Tags: #banking · #audit · #compliance · #kvkk · #bddk

When the regulator asks who changed what and when, the platform team answers — or does not. With most API gateways, the answer is "we'll get that for you" followed by a multi-day investigation across logs, tickets, and Git history.

Apinizer was built so the answer is one query against a single audit trail. This post walks through the three controls that matter to banking auditors and how they are wired into the platform.

1. Audit at the persistence layer

Every Repository.save and Repository.update in the Manager goes through the same audit aspect. There is no opt-out. There is no "audit service" you can forget to call. The framework rejects the call if the aspect cannot fire.

// Audit aspect catches every Repository.save
@Aspect
@Component
public class AuditAspect {
    @Around("execution(* org.springframework.data.repository.Repository+.save(..))")
    public Object captureChange(ProceedingJoinPoint pjp) throws Throwable {
        // Actor, timestamp, before/after delta, reason
        ...
    }
}

The audit log records the actor, the timestamp, the before and after state of the entity, and an optional reason. Same for proxy deploys, permission grants, credential rotations.

2. Encrypted secrets — by annotation, not by convention

Every field marked @SecretData is encrypted before it hits the database and decrypted only when the runtime needs it.

public class ConnectionEntity {
    @SecretData
    private String dbPassword;     // never persisted in plaintext

    @SecretData
    private String oauthSecret;    // same
}

This includes credentials, OAuth client secrets, JWT signing keys, LDAP bind passwords. The encryption is keyed per environment, and the keys themselves rotate without breaking in-flight tokens.

3. Three-tier permissions, end to end

Apinizer's PermissionService enforces three tiers:

System — platform admins, infrastructure, license
Project — product or domain ownership
Team — operators and developers within a project

Every read, write, and deploy in the Manager flows through PermissionService.check(). Same for APIops applies. Same for Portal subscription approvals. Same for AI Gateway route changes.

The auditor doesn't need a custom report. They get the trail by querying the audit Elasticsearch index for actions touching Project: Payments between two dates.

What this looks like for an audit

A typical audit conversation for a bank running Apinizer:

Auditor: "Show me every change to the payments API in Q4." Platform team: Three queries — one for proxy changes, one for permission grants, one for credential rotations. Output is CSV per query, 12 minutes total.

Compare to a typical answer with a hand-rolled middleware audit:

Auditor: Same question. Platform team: "Give us a week."

What's not in this post

This post covered audit, secrets, and permissions. Banking customers also care about: data masking on responses, BDDK / PSD2 alignment, mTLS, IP allowlisting, time-restriction policies, and Anomaly Detector. We'll cover those in a follow-up.

If you want to see how this fits your bank, the team is one form away.

All posts · Book a Demo · Read the docs