Skip to main content
This document is intended for security, risk, and compliance professionals. It provides a detailed description of the controls governing our Delegated Access and Human-in-the-Loop (HITL) operating model. These controls are designed to meet the requirements of SOC 2 (Trust Services Criteria for Security, Availability, and Confidentiality) and align with the principles of the NIST Cybersecurity Framework.

1. Access Control (NIST PR.AC)

Control IDControl DescriptionImplementation
AC-1.1Delegated Access MandateThe Waycore platform requires customers to create a dedicated, limited-permission user account (“Delegate User”) within their own financial institution’s portal. The use of primary or administrator credentials is programmatically and contractually prohibited.
AC-1.2Credential EncryptionAll Delegate User credentials are encrypted at rest using AES-256 and a dedicated, customer-specific key managed by our cloud provider’s Key Management Service (KMS). Raw credentials are never stored in plaintext and are not accessible by any human operator.
AC-1.3Role-Based Access Control (RBAC)Customer administrators define roles and permissions for their own users within the Waycore platform. These roles determine which users can create, approve, and execute workflows.
AC-1.4Internal Access ControlAccess to production systems by Waycore employees is restricted based on the principle of least privilege. Access requires multi-factor authentication (MFA) and is logged and audited. Direct access to customer data is prohibited for all employees except a small, designated team of on-call engineers for emergency break-fix scenarios.

2. Human-in-the-Loop (HITL) and Approval Workflows (NIST PR.IP)

Control IDControl DescriptionImplementation
IP-2.1Human Supervision of Automated SessionsAll automated sessions are supervised by trained human agents. Agents have the ability to monitor, pause, and terminate any session at any time.
IP-2.2Automated Escalation RulesThe automation platform is configured to automatically pause and escalate to a human agent for review and approval under predefined conditions, including: (a) encountering a system error or unrecognized UI element; (b) before executing a high-risk action (e.g., payment initiation); or (c) if a data validation check fails.
IP-2.3Segregation of DutiesThe roles of workflow creator, approver, and executor can be segregated within the Waycore platform to enforce separation of duties. A user who creates a workflow cannot approve their own workflow unless explicitly permitted by the customer’s configuration.
IP-2.4Multi-Step ApprovalsThe platform supports optional multi-step and multi-user approval workflows for high-risk or high-value transactions, as defined by the customer.

3. Audit and Accountability (NIST DE.CM)

Control IDControl DescriptionImplementation
CM-3.1Immutable Audit TrailAll actions taken within the Waycore platform, including user logins, workflow creation, approvals, automated system actions, and human agent interventions, are logged to a tamper-evident, append-only audit trail.
CM-3.2Log RetentionAudit logs are retained for a minimum of 12 months. Log data is stored in an encrypted format and protected from unauthorized access or modification.
CM-3.3External Audit TrailAll actions performed by the Delegate User are logged within the financial institution’s own native audit trail, providing an independent, customer-accessible record of activity.
CM-3.4Log ReviewAutomated alerting is configured to detect and flag anomalous activity in the audit logs for review by our security team. A formal review of all high-risk events is conducted on a monthly basis.

4. System and Services Acquisition (NIST ID.SC)

Control IDControl DescriptionImplementation
SC-4.1Third-Party Risk ManagementAll third-party subprocessors are subject to a formal risk assessment and due diligence process before being onboarded. We maintain a list of all subprocessors, which is available to customers upon request.
SC-4.2Secure Development Lifecycle (SDL)Our software is developed in accordance with a formal SDL process, which includes mandatory security training for developers, static and dynamic code analysis, and regular vulnerability scanning.