Built for procurement-grade
scrutiny
Kenal AURA runs on a multi-cloud regional footprint spanning AWS Malaysia and GCP Singapore, engineered to meet each country's data residency requirement, with encryption, tenant isolation, immutable evidence retention, and PDPA alignment. The posture below answers the security questionnaire your procurement team will send us.
A concrete security posture, not a wall of logos.
Acquirers, PSPs, and fintechs operate in a regulated environment. The platform they pick needs to answer the hard questions on data residency, encryption, retention, and tenant isolation up front, before the security review starts, not after.
This page summarizes the control patterns Kenal AURA has shipped. Every claim on this page is backed by the production infrastructure configuration, not by intention.
Regional hosting. Multi-cloud by design.
Kenal AURA is deployed across two regional clouds: AWS ap-southeast-5 in Malaysia and GCP asia-southeast1 in Singapore. Tenants are placed on the regional cloud that meets the data residency requirement of the country they operate in, and production stores do not silently replicate across regions.
The multi-cloud footprint exists for two reasons. First, it lets each tenant stay inside the jurisdiction its regulator expects: Malaysian acquirers stay on the Malaysia region to keep PDPA and Bank Negara Malaysia expectations satisfied, Singapore tenants stay on the Singapore region. Second, it provides provider-level redundancy: a prolonged outage in one cloud does not take the whole platform down.
Encrypted at rest and in transit by default.
All S3 buckets (evidence, onboarding captures, compliance reports, and audit logs) are configured with AES-256 server-side encryption. Public access is blocked at the bucket level. The relational database runs with storage encryption enabled. The Redis cluster has both transit encryption and at-rest encryption enabled.
Service-to-service traffic runs over TLS. External API calls to registry and verification providers run over TLS. Secrets and signing keys live in a dedicated secrets manager, never in application environment dumps.
Evidence is immutable for seven years.
The evidence bucket is versioned and protected by S3 Object Lock in COMPLIANCE mode with a 2,555-day default retention (seven years, aligned to card-scheme evidence retention expectations). Objects cannot be overwritten or deleted before retention expires, not even by platform administrators.
A lifecycle rule transitions evidence to STANDARD_IA after 365 days and to GLACIER after 730 days, controlling storage cost without breaking the retention guarantee. Every evidence access is logged into a separate immutable audit-log bucket for chain-of-custody review.
Every query is scoped by acquirer.
Kenal AURA is multi-tenant. Every merchant, scan, case, evidence blob, and report is tagged with the acquirer ID of the acquirer who owns it. Database access is row-scoped by that acquirer ID at the data-access layer, not trusted to a UI filter.
Administrative surfaces that span multiple acquirers are restricted to platform-level operators and are not exposed to acquirer users. An acquirer-tenant user cannot reach, enumerate, or even count data belonging to another acquirer tenant.
Role-based access, session-scoped everywhere.
Sessions are issued through NextAuth with a server-held signing secret. Role-based access control (RBAC) defines what each user can see and do inside their tenant (risk analyst, compliance officer, administrator), with action-level gating for destructive operations.
Admin actions (adding users, changing retention policies, exporting evidence bundles) are audit-logged with actor, timestamp, and affected entity. The audit log is written to the same immutable bucket as evidence access.
Operational readiness, not brochure claims.
Monitoring alerts route to a dedicated ops channel with on-call coverage. Security-impacting events trigger a pre-defined triage path that includes scope assessment, containment, and stakeholder notification to affected acquirer tenants.
A post-incident review document is produced for every significant event and retained inside the audit log bucket. Incident reviews feed back into control hardening so the same issue does not resurface.
Frequently asked questions
- Is Kenal AURA SOC 2 or ISO 27001 certified?
- The platform is engineered against the control patterns used in SOC 2 CC6 and CC7 and ISO 27001 A.12: immutable evidence, audit trail, encryption at rest, access logging. Formal attestation is a separate process and is pursued on a per-deployment basis when a buyer contract requires it. We will not claim a certification we do not hold.
- Where is my data physically stored?
- Production Kenal AURA is deployed across AWS Malaysia (ap-southeast-5) and GCP Singapore (asia-southeast1). Each tenant is placed on the regional cloud that meets the data residency requirement of its jurisdiction: a Malaysian acquirer lands on the Malaysia region, a Singapore tenant lands on the Singapore region. Primary stores, backups, and evidence buckets stay within the assigned region. We do not silently replicate production data outside the country it belongs to.
- Does Kenal AURA run on a single cloud?
- No. Kenal AURA runs on a multi-cloud regional footprint: AWS Malaysia (ap-southeast-5) and GCP Singapore (asia-southeast1). The dual-provider posture means a prolonged outage in one cloud does not take the whole platform down, and it lets us place each tenant in the region that meets their data residency requirement rather than forcing every tenant into one provider's geography.
- How is data from different acquirers kept separate?
- Every merchant, scan, case, and evidence artifact carries an acquirer identifier. Data access at the application layer is row-scoped by that identifier. An acquirer tenant cannot query, enumerate, or aggregate data belonging to another acquirer tenant, not through the UI, not through the API, not through search.
- Can evidence be tampered with or deleted?
- The production evidence bucket is configured with S3 Object Lock in COMPLIANCE mode with a 2,555-day retention window. Objects cannot be overwritten or deleted before retention expires, and the lock cannot be lowered inside that window. This is a regulatory-grade immutability posture, not a soft retention flag.
- What happens to evidence after seven years?
- The evidence bucket lifecycle expires objects at day 2,555 (seven years), aligned to card-scheme retention expectations. Buyers who need longer retention can configure an extended window at contract time. Buyers who need shorter retention cannot go below card-scheme minimums without acknowledging the scheme-compliance implication.
- How are PII fields like MyKad and selfies handled?
- MyKad photos, selfies, and OCR outputs live inside the onboarding storage bucket under the same AES-256 encryption and public-access-block configuration as every other artifact. Access goes through the same role-based scoping as any other tenant data. Nothing sensitive is ever rendered in a public URL.
- Is the platform aligned to Malaysia's PDPA?
- Yes. Malaysian tenants are placed on the AWS Malaysia region so PDPA data residency stays satisfied. Retention periods are disclosed, and access controls, tenant isolation, and the right-to-erasure workflow are aligned to PDPA principal rights. Buyers requiring a formal PDPA mapping document can request one during procurement.
- Do you support customer-managed encryption keys?
- The default configuration uses provider-managed keys in the tenant's assigned region: AWS KMS on the Malaysia region, Google Cloud KMS on the Singapore region. Customer-managed encryption keys (CMK) can be enabled per tenant as a contracted option. Key rotation and break-glass procedures are documented before enablement.