Risk, resilience and compliance · API security · Tokenisation · Zero trust
A controlled edge for partners, fintech suppliers and SaaS platforms that need regulated data. Each partner is authenticated, authorised per scope, rate limited and logged, sensitive fields are tokenised, and everything is encrypted with keys you hold.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
A partner calls the API over TLS 1.2 or higher. The public edge applies web application firewall rules, rate limits and DDoS protection before any application code runs.
Filtered traffic reaches the API gateway, the single entry point for partners. There is no direct path to the data store or internal services.
The gateway validates the partner's mutual TLS certificate and OAuth client credentials. Each partner has its own client, scopes, quota and expiry, so access can be revoked without affecting others.
An authorised call reaches an integration service that validates the schema, applies field-level minimisation (only fields the partner is entitled to), and rejects anything unexpected.
Sensitive values, such as card numbers, tax file numbers or account identifiers, are replaced with tokens before they travel to or from the partner. The partner works with the token and never sees the original value.
The mapping between token and original value sits in a token vault inside the regulated data network. Only the tokenisation service, using narrow permissions, can read it.
The regulated data store receives only what it needs. It has no internet route and accepts connections from named services in the core network.
Encryption keys are customer-managed in KMS with separate administrators and users. Rotation and key access are logged, and a key can be disabled during an incident.
Updates to partners are sent asynchronously through a queue, with retries, dead-letter handling and signed webhooks, so the boundary does not depend on partner uptime.
API calls, authorisation decisions and data access are written to an immutable log. This is the evidence for CPS 234 reviews, partner disputes and incident investigations.
| Component | What it does | Why this choice |
|---|---|---|
| AWS WAF and Shield | Filters malicious requests and absorbs volumetric attacks. | Protects the single public entry point. |
| API Gateway with mutual TLS and OAuth | Authenticates partners, applies scopes and quotas, and records every call. | One place to enforce policy for every partner. |
| Integration service | Validates, minimises and maps data between your model and the partner's. | Keeps partner formats out of your core systems. |
| Tokenisation service and vault | Replaces sensitive values with tokens, with the mapping held in a protected vault. | Reduces exposure in the event of partner compromise, and reduces PCI DSS scope where cardholder data is involved. |
| AWS KMS with customer-managed keys | Encrypts data and tokens, with logged use. | You control the keys and can revoke access. |
| Event queue | Decouples updates and handles retries. | Isolates partner failure from your operations. |
| Immutable audit log | Retains authentication, authorisation and data access records. | Supports investigation and assurance. |
Partner authentication
Why. Binds a request to a certificate and a scoped identity. Revocation is per partner.
Trade-off. Certificate lifecycle needs automation or it causes outages.
Tokenise or encrypt fields
Why. A token carries no value if leaked, and keeps partner systems out of scope.
Trade-off. Tokenisation adds a dependency and latency. Make the service highly available.
Pull or push
Why. Reduces the number of outbound paths from the core network.
Trade-off. Webhook delivery needs retries and monitoring.
Network exposure
Why. Matches exposure to risk.
Trade-off. Private connectivity takes longer to set up and has its own cost.
Data minimisation
Why. Limits what a breach at a partner can expose, in line with the Australian Privacy Principles.
Trade-off. More onboarding work for each partner.
Defence in depth: edge filtering, strong partner identity, field minimisation, tokenisation, encryption with customer-held keys, private data networks and immutable logs.
Multi-zone gateway and services, retries and dead-letter queues, circuit breakers per partner and clear degradation behaviour.
Gateway caching for reference data, connection reuse and asynchronous processing for non-urgent updates.
Gateway and WAF cost scales with traffic. Use usage plans and caching and avoid chatty polling by partners.
Partner onboarding checklist, certificate rotation automation, quarterly access review and a documented offboarding path.
Reduce redundant partner calls with event delivery and caching.
Public edge services in the boundary VPC. Core services and data in a separate VPC with no internet route, reached through private endpoints. Egress to partners is by allow-list through an inspected path. Segmentation limits lateral movement.
Each partner is a registered client with named technical and business contacts, scopes, quota and expiry. Staff access to the boundary and the vault is through the workforce identity provider with MFA and just-in-time elevation. Secrets and certificates are stored in a secrets service and rotated.
Classify each data element, decide whether the partner needs it in clear, tokenised or at all, and record the purpose. Keep all copies in Australian regions unless an offshoring decision is approved and recorded. Define retention, deletion and return of data at end of the arrangement.
| Control | How this design addresses it |
|---|---|
| Third-party information assets | Assess the partner's security capability and restrict what they receive. CPS 234. |
| Material arrangements | Formal agreement terms, monitoring and notification supported by logs and usage reporting. CPS 230. |
| Protection of personal information | Minimisation, encryption and access control support APP 11, with cross-border disclosure considered under APP 8. |
| Protect stored account data and transmissions | Tokenisation and strong cryptography help reduce PCI DSS scope. Scope still needs assessor confirmation. |
| Restrict administrative privileges and MFA | Just-in-time admin access and MFA for staff. Essential Eight. |
| Logging and monitoring | Retained, tamper-evident logs. ISO/IEC 27001:2022 and CPS 234. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
| Failure mode | Mitigation |
|---|---|
| Partner credentials compromised | Per-partner revocation, certificate pinning to client identity, anomaly alerts on volume and pattern. |
| Partner sends malformed or malicious data | Schema validation, size limits and WAF rules, with dead-letter handling. |
| Tokenisation service unavailable | Multi-zone deployment, circuit breaker and graceful degradation to reject rather than pass clear data. |
| Certificate expiry | Automated renewal, expiry alerts at 30, 14 and 7 days, and a tested manual fallback. |
| Partner outage | Queues, retries and visibility of backlog to the business owner. |
| Over-sharing through scope creep | Quarterly scope review and removal of unused scopes. |
Gateway request charges, WAF rules, tokenisation compute, KMS requests and log storage.
AWS · CPS 230 · Resilience
A technical design that traces each critical operation to the services behind it, sets recovery capability from tolerance levels, replicates to a second region, and proves the result through game days and continuous service-level monitoring.
Multi-cloud · Exit planning · CPS 230
How to depend on cloud, SaaS and AI providers without being trapped by them: a provider register tied to critical operations, a portability layer you own, tested data export and a second-provider path for the services that matter most.
AWS · Azure · Continuous compliance
Turn point-in-time audits into continuous assurance. Cloud configuration, findings and policy results flow into one evidence store, are mapped to named controls across several standards, and reach owners and auditors through dashboards and read-only access.
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.