Platform Module
One platform. Many tenants. Hard boundaries.
Kenal AURA is built as a multi-tenant operating platform. Each acquirer, PSP, or payfac runs as a first-class tenant with its own plan, scan cadence, enabled features, branding, and per-country cloud placement, isolated at the platform layer.
How it works
Provision the tenant
Register the acquirer institution with its legal name, Mastercard ICA, and contact email. Assign the plan that defines its enabled features and quotas.
Configure per-tenant policy
Set the scan cadence, BRAM rule overrides, MCC allow list, and SLA clocks. Policy is layered: system defaults, then acquirer overrides, then per-application overrides.
Isolate and operate
Every query, every scan, every investigation is row-scoped by acquirer ID. Analysts see only their portfolio. Tenants on Malaysian data residency land on the AWS Malaysia region automatically.
Acquirers
All registered acquirer institutions
| Acquirer | Plan | Alerts |
|---|---|---|
| Kedar Pay Sdn Bhd | Enterprise | 12 |
| Sinar Acquiring | Growth | 3 |
| Arah Payments Bhd | Growth | 0 |
| Maya Commerce | Standard | 1 |
First-class tenant model
Acquirers are not tags on merchants. Every acquirer is a tenant entity with its own plan, ICA, enabled features, branding assets, contact channel, and scan cadence. Adding a new acquirer is a first-class operation, not a schema migration.
Layered configuration
Configuration cascades through three layers: system defaults, per-acquirer overrides, and per-application overrides at onboarding time. A Kenal-maintained BRAM rule set ships by default, an acquirer can add its own overrides, and an individual onboarding case can override both for a specific merchant review.
Feature gating per plan
Plans define which features a tenant can access: adverse media screening, entity discovery, multi-locale geo-cloak detection, mobile onboarding app, and so on. Gating is enforced at the API layer, not just the UI, so a tenant cannot call an endpoint for a feature their plan does not include.
Row-scoped data isolation
Every tenant-scoped table carries an acquirer ID. Every query the application runs is filtered on that column. A misconfigured dashboard cannot leak another acquirer's merchants, alerts, or evidence. The query simply returns an empty result. Isolation is enforced at the data access layer, not the presentation layer.
Frequently asked questions
- How does tenant isolation actually work?
- Every tenant-scoped table carries an acquirer ID column. Every query the application layer runs is filtered on that column. Dashboards, APIs, scans, alerts, and investigations are all row-scoped. A user provisioned for acquirer A cannot read acquirer B's data even if they guess a record ID. The query returns empty.
- Can different tenants live on different clouds?
- Yes. Production Kenal AURA runs on a multi-cloud regional footprint: AWS Malaysia (ap-southeast-5) and GCP Singapore (asia-southeast1). Each tenant is placed on the regional cloud that meets its country's data residency requirement. Malaysian acquirers land on the Malaysia region, Singapore tenants land on the Singapore region. Placement is a per-tenant configuration at provisioning time.
- Can a tenant have its own BRAM rules or MCC policy?
- Yes. A system default rule set ships with the platform, and each acquirer can layer overrides and custom rules on top. The same applies to MCC allow lists and scan cadence. Each tenant can tune the operating envelope to its own risk appetite without affecting other tenants.
- How are new tenants onboarded?
- A super-admin provisions the acquirer with name, ICA, contact email, and plan. The plan defines the enabled features and quotas. From there, the acquirer team can invite users, upload its existing merchant portfolio via bulk CSV, and start the baseline scan cycle. A typical new tenant is live within a week.