HR Blizz Platform Architecture Overview
The HR Blizz architecture described at the depth required for client security assessments, enterprise architecture reviews, and IT due diligence — a horizontal, single-codebase global payroll platform engineered, owned, and operated end to end by Mercans.
Executive Summary
HR Blizz is Mercans' proprietary global payroll and HR platform, engineered, owned, and operated end to end by Mercans. The platform runs on a Mercans private cloud across eight data center regions and processes gross-to-net payroll natively — Mercans owns the application code, the database tier, the integration layer, the encryption infrastructure, and the in-country delivery operations. No third-party aggregators sit between the platform and the payroll outcome.
This document describes the architecture a security assessor needs to evaluate: a three-tier topology behind layered firewalls, a microservices architecture orchestrated on Kubernetes behind a Cloudflare-protected edge, a five-database data model with per-client database isolation, an API-first integration layer, defense-in-depth security controls across transport, account, big-data, and data-at-rest layers, a real-time mirrored disaster recovery model, and a GitLab CI/CD pipeline deploying to Kubernetes through build, test, and registry stages.
Architecture Position
HR Blizz is a horizontal platform: modular, reusable components serve every country from a single codebase, in contrast to legacy vertical payroll stacks that re-implement logic market by market. This is the structural reason the platform scales across 160+ countries without per-country forks.
Platform Overview
HR Blizz unifies global payroll data and employee information into a single secure interface, accessible from any device in real time. The platform exposes the following functional surface:
The HR Blizz product family comprises the core platform, Employee Self Service, and a published API set. Every module is API-enabled with token-based authentication and auditable transactions.
Architectural Principles
Mercans builds HR Blizz on four engineering principles. They are design constraints, not aspirations — every component in this document traces back to at least one of them.
Agile
Continuous improvement, fast releases, fast fixes. The CI/CD pipeline in Section 15 operationalizes this.
Modular
Independent services reduce build time, enable parallel products, and scale the engineering team.
Scalable
Teams, datasets, and load balancing all scale horizontally; load is spread across replicated database nodes.
Secure
Encryption everywhere, mirrored data, and proprietary code. Security is a tier in the architecture, not a feature.
Three-Tier Architecture
HR Blizz separates the exposed edge, internal compute, and persistent data into three tiers divided by two firewall boundaries. Client traffic enters through the Cloudflare edge and EU/APAC routers; the application tier operates behind it; a second, internal firewall isolates the database tier. No path exists from the public edge to a database without crossing both boundaries, and no event reaches the processing layer without crossing the AI layer.
HR Blizz Three-Tier Architecture
Cloudflare edge · regional routing · decomposed application tier · isolated database tier
Figure 1 HR Blizz three-tier architecture: Cloudflare edge, regional routing, and the decomposed application tier (service & API layer, AI layer, processing layer).
- Client / User tier: web, mobile (iOS/Android), ESS portal, and API clients connect over enforced TLS v1.2+ through the Cloudflare edge — DNS, CDN, WAF with DDoS protection, bot management, and IP access rules, and Zero Trust controls — then through EU and APAC routers providing firewall, IP filtering, NAT, and load balancing.
- Application tier — three sub-process layers: the service & API layer exposes the SSO, HRB, Validation, Payroll, Loader, and ESS APIs — token-based and auditable; the AI layer applies field-level data validation, anomaly detection, touchless payroll automation, and in-line compliance checks to every event; the processing layer executes the work — the G2N Engine performs gross-to-net calculation against country statutory rules drawn from the Tax Database (including retro, proration, and multi-run processing), and job engine agents run scheduled and queued payroll, report generation, and EFT/WPS and GL file production.
- Database tier: five database types separate concerns — Control (site configurations, users), Client (per-client isolation), Master Data (common and base data), Tax (tax data, country regulations), and Admin (global administration, monitoring, central login).
Private Cloud Infrastructure
HR Blizz runs on a private cloud model — Mercans-controlled infrastructure, not shared public multi-tenant compute. Private cloud data centers operate in eight regions, giving clients regional data residency options across North America, Europe, the Middle East, Asia-Pacific, Africa, and Latin America.
Global Private Cloud Footprint
Eight Mercans-controlled regions · IPSec-connected · data residency follows the contracted region
Figure 2 Global private cloud footprint with IPSec-connected regions.
The internal network is segmented into distinct VLANs for security and operational efficiency, with remote access strictly regulated through secure VPN connections limited to authorized personnel. The physical layer is built on Dell and Supermicro hardware with Red Hat and VMware virtualization. Persistent storage runs on Dell hardware. Each location operates S3 storage clusters with dedicated backup storage; inter-site traffic crosses IPSec VPN tunnels with AES-256 encryption and TLS v1.2 using 4096-bit / SHA-256 certificates.
Microservices Architecture & Technology Stack
HR Blizz uses a service-oriented, containerized architecture orchestrated by Kubernetes. Cluster nodes host pods running the platform's services; each payroll function operates as an independent service backed by shared logic libraries, so components deploy — and roll back — in isolation. The G2N Engine and AI services run as dedicated pods in the processing & intelligence layer, scaling independently of the application and database pods that surround them.
Microservices (SOA) Topology on Kubernetes
Routing → service pods → storage & database clusters · control plane orchestrates the estate
Figure 3 Microservices (SOA) topology on Kubernetes.
Technology stack
| Layer | Technologies |
|---|---|
| Languages | Java SE/EE · C/C++/C#/Objective-C · Android & iOS (mobile) |
| Databases | Oracle Database · MySQL · MongoDB · PostgreSQL |
| Frameworks & runtimes | Spring Framework · JavaEE · JBoss |
| Orchestration & CI/CD | Kubernetes · GitLab CI/CD (build, test, registry, deploy) · Maven |
| Engineering tooling | IntelliJ IDEA · OpenProject · HashiCorp Vault (key management) |
| Edge & delivery | Cloudflare — DNS · CDN · WAF · DDoS protection · Zero Trust |
| Service APIs | SSO API · HRB API · Validation API · Payroll API · Loader API · ESS API |
| Physical & virtualization | Dell · Supermicro · Red Hat · VMware · S3 storage clusters |
Database Architecture & Client Isolation
The five-database model separates configuration, tenant data, shared reference data, tax and regulatory content, and platform administration. The isolation property that matters most to a security assessment: each client is provisioned a separate Client Database holding that client's users, security configuration, updates, and recovery data. Client transactional and security state is never co-mingled across tenants.
| Database | Contents & role |
|---|---|
| Control Database | Site configurations and users — platform-level control plane. |
| Client Databases | One per client: users, security, updates, recovery. The tenant isolation boundary. |
| Master Data | Common data and base data — shared reference services consumed across tenants. |
| Tax Database | Tax data and country regulations — the statutory rules engine content, maintained centrally by Mercans. |
| Admin Database | Global administration, monitoring, and central login. |
Big-data isolation controls
- Raw data cannot be accessed outside the virtual machine that hosts it.
- SQL access is permitted only from machines inside the same virtual network.
- VM access is restricted to predetermined IP addresses using SSH keys with the RSA algorithm.
- Load is handled by multiple nodes accessing multiple replicated databases — no single choke point, no single copy.
- All data at rest is encrypted with AES-256.
API & Integration Architecture
HR Blizz is API-first. Inbound integrations terminate at a web application firewall before reaching the validation layer; nothing persists without passing validation. Outbound delivery is queued, validated, and proxied. Three integration patterns cover the client landscape: the standard interface, schema-based client integration, and the HCM connector layer (DIP).
Standard interface
Standard Interface — Inbound & Outbound
Inbound REST through WAF and validation · outbound via task queue and proxy
Figure 4 Standard interface: inbound REST with WAF and validation; outbound via task queue and proxy.
- Inbound (REST API): Global HRMS systems send hire / data_change / termination events; timekeeping and benefit providers send data_change events. All traffic crosses the MD Proxy WAF, then the Validation API working with the Master Data API and Event Scheduler, before persistence into HR Blizz.
- Outbound (flat file or REST API): HR Blizz pushes approved output to a task queue; the Validation API, Report Engine, and Event Scheduler prepare delivery; the Outbound Proxy delivers to payment processors, remote SFTP servers, and ERP systems.
Defined and dynamic schema integration
Figure 5 Defined schema (REST, mTLS) and dynamic schema (SFTP/CSV, dynamic parser) client paths.
- Defined schema: client systems call the REST API — secured with mTLS, IP whitelisting, and basic authentication — into the Master Data API (master data, timesheet, leave, pay elements & deductions, HR fields), through the Payroll Admin Console with automatic persistence and validation, into payroll and reports.
- Dynamic schema: clients deliver CSV over SFTP — secured with SSH key authentication and IP whitelisting — into the Dynamic Parser, triggered from the Payroll Admin Console, feeding the same Master Data API. The parser absorbs schema variation so the client does not have to conform to a fixed file layout.
HCM connectors — Dynamic Inbound Processor (DIP)
DIP is the integration layer for enterprise HCM platforms — Workday, UKG Pro, UKG Dimensions, and WFC. It accepts Workday PECI XML and flat files over SFTP and converts employee lifecycle events into payroll lifecycle events through data mapping (XSLT), a robust validation layer, and configurable automation rules. DIP ships prepackaged with country-specific data templates and is fully customizable per client.
- Transport security: SFTP with SSH public-key authentication, IP whitelisting, and PGP encryption and signatures on file content.
- Supported events (standard scope): hire, rehire, transfer, termination, termination cancellation, and data changes — master data, pay components, one-time elections, and evaluated LOA and T&A transactions.
- Exception handling: every event passes the validation layer; validation errors are aggregated into an exception report identifying the employee, the event, and the error message, and returned for correction.
- Controlled limitations: employees from multiple legal entities are sent separately for security; hire and termination dates change only while an event is queued (not persisted); after payroll is processed, dates cannot change through the interface; retroactive changes are not accepted beyond the first payroll period.
Security Architecture
Security in HR Blizz is layered: every tier, transport path, and storage location carries its own enforced controls. The table below is the assessor's map of control to layer; the transport model follows.
| Layer | Enforced controls |
|---|---|
| Edge | Cloudflare WAF traffic sequence — DDoS protection · IP access rules · bot management · URL, page, origin & cache rules · load balancing to origin |
| Transport | AES-256 encryption · IPSec VPN between locations · TLS v1.2 enforced, 4096-bit / SHA-256 certificates |
| Account | SAML 2.0 single sign-on with all common identity providers (Azure AD, Okta, Auth0) · OAuth 2.0, OIDC, LDAP, and ADFS supported · multi-factor authentication · TLS v1.2+ on all sessions · 1-hour password-creation tokens · minimum 8-character passwords |
| Application boundary | Perimeter firewall + load balancers · internal firewall before the database tier · WAF on inbound integration · outbound proxy on delivery |
| Big data | Raw data inaccessible outside the VM · SQL access only within the same virtual network · VM access from predetermined IPs via SSH key (RSA) · multi-node, multi-replica load handling |
| Data at rest | AES-256 across storage · daily encrypted, password-protected backups · server-side storage only — no client data on local devices |
Transport Security
IPSec between locations · TLS to the public edge · encrypted storage and backup at each site
Figure 7 Transport security: IPSec between locations, TLS to the public edge, encrypted storage and backup at each site.
Identity & Access Management
Access to HR Blizz and to the systems that operate it is governed by formal authorization at every layer — user, machine, and support tooling. The controls below apply across production systems, internal support tools, and customer data.
Client user authentication — SSO and MFA
Clients enable single sign-on for HR Blizz using SAML 2.0 as the standard, giving their users one-click access through their existing identity provider — Azure Active Directory, Okta, Auth0, and all common IdPs are supported — without separate passwords stored in HR Blizz. Mercans supports all major authentication protocols out of the box. Multi-factor authentication protects access to sensitive systems and applications.
Internal authorization controls
- Machine authentication: machine-level access relies on a certificate-based distributed authentication service; digital certificates are issued by an internal Mercans certificate authority and provide transport encryption alongside identification. All data traffic — including Mercans-internal traffic — is encrypted.
- Support tooling: internal support tools used by operational and technical staff are controlled via access control lists, limiting use to specifically authorized individuals.
- Remote access: remote access to Mercans corporate machines requires a Mercans-issued digital certificate installed on the connecting device plus two-factor authentication.
- Least privilege & role-based access: production access is granted only at the level required for the task, using predefined security groups for role-based privileges; access requests are documented, manager-approved, and logged through workflow tools.
- Periodic reviews & deprovisioning: group memberships are reviewed semi-annually by group administrators; system owners review production access periodically; all corporate and production access is removed automatically on submission of a termination request.
- Security training: security and privacy training is part of personnel onboarding.
Key Management
Cryptographic keys are stored and managed in Mercans' private HashiCorp Vault. TLS certificate management is a fully automated process; all other certificate changes follow the Mercans change management process. Digital certificates used for machine authentication and internal data encryption are issued by the internal Mercans certificate authority, and bank-file signing and encryption keys are generated and held on the Mercans encryption server — private keys never leave it.
In one line
One system of record for secrets, one automated lifecycle for TLS, one controlled process for everything else.
Audit Logging & Monitoring
All user activities in HR Blizz are logged and time-stamped, and activity logs are monitored electronically on an ongoing basis — business-critical actions trace to a specific user. Logical access to audit logs is restricted to authorized personnel.
- Continuous monitoring: audit logs are monitored continuously to detect intrusion attempts and other security events; alerts are generated against predefined thresholds and routed automatically to security personnel.
- Vulnerability management: monitoring tools detect and report application vulnerabilities; antivirus, phishing detection, secure coding, and antimalware/antispam tooling protect Mercans information assets. When a vulnerability is identified, the Data Security Team determines the response and tracks the issue through resolution, with component owners responding per severity and defined response criteria.
- Retained events: audit logs are retained for privileged user access activities, authorized access attempts, and unauthorized access attempts. System logs, admin event logs, and audit logs are retained for 180 days.
Backup & Data Retention
Mercans backs up comprehensively every day, and captures delta snapshots of data changes twice daily — minimizing potential data loss in real-time operations. Backup retention runs 31 days on local servers with one-year archival at external locations, after which data is assessed for deletion subject to the data owner's approval. Client contracts and legal or regulatory requirements supersede this default policy.
- Client-controlled retention: retention criteria and retention periods are determined by the client, not by Mercans. Company and employee information is retained, stored, scrambled, and destroyed in line with legislative and regulatory guidelines, with periodic reviews of purpose, validity, accuracy, and continued need.
- Data subject requests: as processor, Mercans does not respond directly to data subject enquiries — every enquiry is forwarded to the client as controller, who responds accordingly.
- Legal hold: records pending audit, litigation, or investigation are protected from destruction or alteration by defined processes.
Disaster Recovery & Business Continuity
All HR Blizz servers are mirrored in real time, and any mirror can be promoted to production at any time. Scheduled updates flow from the production site to the disaster recovery site, with cross-mirroring for local distribution. On a disaster event, the mirror is promoted to a writable volume and the DR site becomes the production site — the recovery mechanism is the same replication machinery that runs continuously in normal operations, not a separate cold-standby process that must be proven under pressure.
Disaster Recovery Model
Real-time mirroring with promotable recovery site
Figure 8 Disaster recovery model: real-time mirroring with promotable recovery site.
Backups reinforce the mirror layer: daily backups of all workstations and storage devices, encrypted and password-protected, with backup storage maintained at every data center location.
Development & Deployment (CI/CD)
Mercans develops HR Blizz on GitLab CI/CD deploying to Kubernetes. All source code commits to the internal version control system, which is integral to testing, building, and deploying across environments — staging, testing, acceptance, and production. Each commit triggers the pipeline: build stage, test stage, push to the container registry, then the deployment stage rolls out to Kubernetes, followed by post-deployment verification with an optional manual approval or manual trigger gate. Every release is registry-versioned and traceable to a commit; components deploy independently and roll back independently.
Figure 9 GitLab CI/CD pipeline to Kubernetes: build, test, registry, deployment, and post-deployment gates.
Compliance & Certifications
Mercans maintains independent attestations and certifications across security, privacy, quality, and service management. Audit reports and certificates are available to clients under NDA through their Mercans account team.
Independent attestation of controls over financial reporting and the trust services criteria (security, availability, confidentiality).
Certified information security management system, first achieved in 2015 and maintained since.
Cloud-specific security controls and protection of personally identifiable information in public clouds.
Privacy information management system extending ISO 27001 to PII processing.
Quality management and IT service management.
Mercans operates as a GDPR-aligned processor under EEA-approved Binding Corporate Rules for Processors, with anonymization, transparency, and accountability as design principles.
Application security verified against the OWASP Application Security Verification Standard.
Assessment Support
Mercans supports client security assessments directly — SOC reports, ISO certificates, penetration test summaries, and completed security questionnaires (SIG, CAIQ) are provided under NDA on request.
