Version 1.2 changes: entitlement (has anyone paid) and permission (may this member) are documented as two separate, non-merged gates (Section 5.4); the AI Chat access boundary is described (Section 5.5); webhook authentication now includes signature verification (Section 7.1); and the offboarding rules were restated — a sole administrator’s departure no longer blocks account deletion (Section 8).
1. Purpose
This Access Controls Policy defines how access to Recontrol’s systems, applications, and data is requested, granted, authenticated, authorised, monitored, and revoked. Its goal is to ensure that only the right people and services have the right access to the right data — and nothing more. It implements the access-control expectations of ISO/IEC 27001:2022 (Annex A controls A.5.15–A.5.18, A.8.2 and A.8.5) and supports the “reasonable security practices” required by the Information Technology Act, 2000 and the SPDI Rules, 2011, and the security obligations of the Digital Personal Data Protection Act, 2023. This policy complements the Information Security Policy, the Data Retention and Disposal Policy, and the Privacy Policy.2. Scope
This policy applies to:- End-user access to the Recontrol applications and to data within collaborative Spaces;
- Administrative / privileged access to production systems (database, Hasura console, cloud platform, secrets); and
- Service and integration access, including machine-to-machine tokens and third-party aggregator connections (Plaid, Zerodha).
3. Principles
- Least privilege. Every user, role, and service receives the minimum access necessary for its purpose.
- Role-based access control (RBAC). Permissions are assigned to roles, and roles to users — not to individuals ad hoc.
- Need-to-know. Access to personal and financial data is limited to where it is genuinely required.
- Deny by default. Access is denied unless explicitly granted; API endpoints require authentication by default.
- Separation of duties / segregation of data. Data in one Space is never accessible to members of another Space.
- Accountability. Actions are attributable to an authenticated identity.
4. Authentication
4.1 User authentication methods
Recontrol authenticates users through the Nhost authentication service. The supported methods are:- Email and password
- Sign in with Google (OAuth)
- Sign in with Apple (OAuth, where available)
4.2 Credential security
- Passwords are stored only as one-way hashes; Recontrol never stores or sees plaintext passwords.
- For Google and Apple sign-in, authentication is delegated to the provider via OAuth; Recontrol never receives your Google or Apple password.
- Users are responsible for keeping their credentials confidential and for using a strong, unique password.
4.3 Tokens and sessions
- On successful authentication, the client receives a signed JSON Web Token (JWT) plus a refresh token.
- Every API request must present a valid JWT (
Bearerscheme); requests without one are rejected by the authentication interceptor before any business logic runs. - Access tokens are short-lived; refresh tokens are invalidated on logout and on account deletion.
- On mobile, tokens are held in platform-native secure storage (iOS Keychain / Android Keystore), never in plaintext app storage.
4.4 Device-level protection
Users may enable an optional biometric app lock (Face ID / fingerprint). This is verified on-device by the operating system; biometric data is never transmitted to Recontrol.5. In-application authorisation (Spaces, roles, and permissions)
Recontrol’s collaborative model enforces authorisation at the data layer through Spaces, roles, and permissions.5.1 Spaces
A Space is an isolated workspace. Data in a Space is visible only to that Space’s members. The user who creates a Space is automatically its administrator.5.2 Roles and permissions
- Permissions are expressed as a resource × action matrix — actions (create, read, update, delete) over resources (such as accounts, transactions, goals, memberships, and roles).
- Administrators may create custom roles with any combination of permissions.
- Two sensible defaults exist per Space: an admin role (full access) and a member role (full access to day-to-day financial data; read-only on administrative resources).
- Role changes take effect immediately for all current holders.
5.3 Membership lifecycle
- Administrators invite members by email or phone number; invitations may wait for recipients who have not yet signed up.
- Members may leave a Space at any time.
- Administrators may change a member’s role or remove a member.
- A Space is never left without an administrator. If the last administrator leaves or deletes their account, the longest-standing remaining member is automatically granted an administrator role. If they were the only member, the Space is deleted with them. Neither case blocks their departure or their erasure.
5.4 Entitlement and permission are two separate gates
Recontrol evaluates two independent questions, in order, and deliberately does not merge them:- Entitlement — has anyone paid for this capability? Bank connections require the Space to be sponsored by an active subscription; AI Chat requires the caller’s own active subscription.
- Permission — may this member perform this action? The resource × action model in Section 5.2.
5.5 AI Chat access boundary
AI Chat runs under the caller’s own identity and access token, so the figures it is given are exactly those the caller’s role in that Space already permits them to read. It has no elevated privilege, no administrative credential, and no write capability of any kind. Text drawn from a user’s own records is passed to the model as delimited data with an explicit instruction that it is never a command, so content inside a ledger cannot be used to redirect the model’s behaviour.6. Privileged and administrative access
- Administrative access to production systems (the database, the Hasura console, the cloud platform, and secrets) is restricted to the Data Fiduciary / owner and any explicitly authorised personnel, on a strict need-to-know basis.
- Privileged credentials (for example, the Hasura admin secret and database credentials) are treated as high-value secrets: held only in protected environment configuration, never committed to source control, and never exposed to clients.
- Administrative operations (such as schema migrations and data backfills) are performed through controlled, versioned, idempotent mechanisms rather than ad hoc production changes.
- Privileged access is reviewed whenever responsibilities change.
7. Service, machine, and integration access
7.1 Internal service authentication
Automated internal calls — such as the scheduled jobs that refresh connected data, the secure webhooks from Plaid that notify us of new bank transactions, the subscription webhooks that report a purchase or renewal, and Hasura cron/event triggers — are authenticated with a shared webhook secret, separate from user JWTs. Webhooks from Plaid and from our subscription provider are subject to two independent checks, both of which must pass: a shared secret that authenticates the caller, and a cryptographic signature over the raw request body that authenticates the payload. A replayed or tampered body therefore fails even if a shared secret were disclosed. In production the service refuses to start if signature verification is not configured. A subscription webhook is treated as a notification, not as an authority: every event triggers an authoritative read from the provider, and the entitlement we record comes from that read rather than from the payload. Entitlement expiry only ever moves forward, so a lost or out-of-order webhook cannot revoke a paying customer’s access.7.2 Third-party integration access (user-authorised)
When a user connects an external institution, access is granted by the user, directly with the provider, using the provider’s authorisation flow:- Plaid: the user authorises through Plaid Link; Recontrol exchanges a one-time public token for a scoped access token (limited to the transactions product). Recontrol never receives the user’s banking credentials.
- Zerodha (Kite Connect): the user authorises through Zerodha’s login; Recontrol exchanges a request token (with a signed checksum) for a daily access token. Recontrol never receives the user’s brokerage credentials.
8. User access lifecycle
9. Access reviews
- Privileged access to production systems is reviewed periodically (and on any change of responsibilities) to confirm it is still required.
- Integration connections are surfaced to users so they can review and revoke connected institutions at any time.
- This policy is reviewed at least annually (Section 11).
10. Responsibilities
11. Review
This policy is reviewed at least annually, and whenever there is a significant change to authentication, the authorisation model, integrations, or applicable law. Material changes are reflected in the “Last Updated” date and version above.12. Contact
- Owner / Grievance Officer: Mrinal Wahal
- Email: support@recontrol.money
- Mailing Address: 2005, Yucca, Paramount Symphony, Crossing Republik, Ghaziabad, Uttar Pradesh, India 201016