Security and trust

Overview

NAVdryx holds capital account records, wire instructions, tax identifiers, and governing documents for private funds and their investors. The platform is designed around a small set of non-negotiable principles rather than security added after the fact: every tenant’s data is isolated by policy, every permission is deny-by-default, every governed record is amended by reversal instead of edited in place, and anything that touches money is calculated deterministically and approved by a person before it is treated as final.

Tenant isolation

Every tenant’s records carry an organization identifier, and access to them is enforced by policy at the database layer — not only in application code that a bug could bypass. A row-level security policy denies access by default; a query has to be explicitly authorized for the requesting tenant to return anything at all. An automated isolation suite, run as part of the platform’s full test suite, checks that one organization cannot read, write, or enumerate another organization’s records.

Access control

Permissions are defined in a single matrix of role, object, and action, and the default for anything not explicitly listed is deny. Roles span both sides of the platform — platform admin, organization admin, fund manager, fund accountant, fund controller, relationship owner, outside auditor, outside tax advisor, outside legal counsel, third-party fund administrator, LP, LP authorized signatory, LP finance contact, LPAC member, and portfolio company user — and each is scoped to what that role actually needs. Some permissions are immutable: posting to a closed accounting period without controller approval, for instance, cannot be granted even by a platform administrator. An LP’s access is scoped the same way as every other tenant boundary — enforced where the data is read, not only in what the interface displays — so an LP can never see another investor’s records regardless of what a misconfigured screen might otherwise show.

Audit trail

Changes to records, sign-ins, and permission changes are logged with the acting user, a timestamp, and the prior and new values where applicable. Sign-in, session, and administrative events also record the IP address. Not every file download and export is logged yet. The log is append-only in practice — write once, never modified through any normal interface, including by a tenant administrator or by NAVdryx’s own staff. Governed financial records follow the same discipline at the record level: a capital event or a calculation is never edited in place once issued. A correction is a new, linked reversing entry, so the full history — including what was later found to be wrong — stays intact and reconstructable.

Encryption

Data is encrypted in transit using TLS. Sensitive fields — wire and bank details, tax identifiers, and third-party access tokens — are encrypted at the field level using AES-256-GCM, masked by default in the interface, and never included in logs, exports, or any AI request. An LP’s security phrase is encrypted the same way and decrypted only to write it into an email to that LP. Any change to a bank account requires dual control from two separate people, callback verification, and a recorded change history, routed through its own approval chain before it takes effect.

Authentication and sessions

There is no public sign-up. NAVdryx creates each organization and invites its first administrator, who invites the rest of the team. An invitation link works once, for seven days, and accepting it sets a password of at least 12 characters. Login attempts are throttled and lockouts apply from day one — this was never treated as a later-phase hardening step. Sessions carry an idle timeout and an absolute timeout, which an organization admin sets, and a user can see their active devices and revoke any session directly.

Two-factor sign-in is required for every GP-side user, who sets it up at their first sign-in, and an organization admin can require it of LP-side users too. An LP who has not set it up is asked to the first time they reveal full wire details. It uses an authenticator app that generates time-based six-digit codes. Each account has one authenticator, bound to it when its first code is confirmed. If the account’s two-factor setup is changed outside NAVdryx, sign-in is refused until an administrator resets it. There are no recovery codes, and there is no SMS or passkey (WebAuthn) option, so a lost authenticator is reset as described under account recovery below.

Account recovery

• Forgotten password. “Forgot password?” on the sign-in page emails a link to choose a new password. The page shows the same message whether or not an account exists for the address, and requests are rate-limited. The link works once, for one hour, and a newer link replaces an older one. Only an active member whose email is confirmed can reset a password this way; someone who has not accepted an invitation yet uses the invitation instead.
• Completing a reset. Choosing a new password signs the user out on every device and does not sign them in. Two-factor sign-in still applies at their next sign-in, and an email confirms that the password was changed.
• Administrator resets. From Admin › Users, an organization admin can send another active member the same password reset email, without ever seeing the link, or reset the member’s two-factor sign-in. Neither works on the admin’s own account, each asks for confirmation, and each needs an authenticator code entered in the last ten minutes. A two-factor reset signs the member out on every device and removes their authenticator, so they set up a new one at their next sign-in. The member gets an email about it, and every other administrator of the organization gets one naming who did it.
• When NAVdryx support steps in. Some two-factor resets are refused with a request to contact NAVdryx support — among them any within 72 hours of the member completing a password reset, so that someone who has taken over a mailbox cannot also have the second factor removed. An organization whose only admin has lost their authenticator contacts NAVdryx support too, which can reset it after confirming the person’s identity outside the product. The member and the organization’s administrators are emailed when support does so.

Every reset link issued, every completed reset, and every administrator or support reset is recorded in the audit trail.

Email trust

An email about a capital call is worth forging, so NAVdryx marks genuine LP emails and gives LPs a way to check them. None of this makes forgery impossible; it makes a forged email easier to spot.

• One sender. LP notice emails come from one verified address, under the display name “<Organization> via NAVdryx”, with no reply-to address. They tell the LP to reply in the portal.
• Verification codes. Every LP notice email carries a code, and so does every notice PDF. A newsletter or legal notice carries one only to a portal user’s own sign-in address, and account emails (invitations, password resets, and security notices) carry none; nor do signature requests, which the e-signature provider sends itself. On the portal’s Emails we sent you page, a signed-in LP sees the emails sent to them with their codes, and can check any code. A check looks only at that LP’s own emails and notices, is limited to ten checks per user per quarter-hour, and is audit-logged.
• Security phrase. An LP can set a private phrase, which appears at the top of emails sent to the address they sign in with, and never on emails to another address. It is field-encrypted and never shown back in the portal. Setting, changing, or removing it emails a security notice to the LP’s sign-in address.
• An optional portal link. A fund can leave the portal link out of its notice emails, in its settings for each kind of notice, for an LP group, or for one send, so its LPs never need to click a link in an email. Such an email has no link, button, or web address; it tells the LP to sign in the usual way, and keeps its code and, where it would carry one, the phrase. Requests to sign, message replies, data-room shares, and alerts about changed bank details or call-back numbers always carry the link.
• Reporting. An LP can report a suspicious email from the portal. The report opens a flagged thread at the top of the fund team’s inbox and notifies them in the app. On the LP side, only the person who filed it can see it, and the fund team’s replies reach them in the portal only, with no email or push. Reports are limited to five an hour per user.
• A security page in the portal explains the phrase, the codes, and reporting to LPs, with the number to call.

Bank details stay in the portal

• No LP email and no notice PDF carries bank details. A notice PDF says that wire instructions are only in the secure portal and that it contains no bank details, and capital call and distribution emails say that the fund never sends or changes bank details by email.
• A tax document is never attached to an email, whatever the fund’s email settings say, because it carries tax identifiers.
• In the portal, an LP sees the fund’s receiving account masked: the bank, the beneficiary, and the last four characters of each number. Revealing the full numbers needs an authenticator code entered in the last ten minutes and is limited to five reveals an hour. The audit record is written in the same transaction as the decryption, so a reveal that can’t be recorded shows nothing. The numbers show for two minutes and are never stored in the browser.
• The mobile app never receives wire details. It shows the warning and the call-back number only.
• On the GP side, revealing a wire instruction needs approve-level access and an authenticator code entered in the last ten minutes, is audit-logged, and is limited to twenty reveals an hour. An instruction that is no longer active is revealed only as an explicitly historical record.
• The message composers on both sides warn against putting bank details in a message.

Change alerts, call-back numbers, and the payout hold

• Change alerts. When a fund’s receiving account is activated, every contact of every affected investor is alerted: investors with an active commitment in the fund, and any investor allocated on one of its sent capital calls that is not yet settled or reversed. When an LP’s payout account is requested or activated, every contact of that investor is alerted. When a call-back number changes, the LPs who see it are alerted. These alerts go to every contact with an email address, portal login or not, and an LP can’t turn them off.
• Call-back numbers. The number LPs are told to call before paying is shown only in the portal and the app, never in an email or a PDF that a forger could alter. Changing it takes two people: one proposes, a different person approves, and each enters an authenticator code from the last ten minutes. For 30 days after a change, LPs see “Changed on” and the date beside the number.
• Wire approvals. The requester, the verifier, and the approver of a wire instruction are three different people, and approving needs an authenticator code entered in the last ten minutes. A new or changed LP payout account is verified by calling a number that was on file before the request, and it can’t be activated without that call-back record.
• The cooling-off hold. Payments to a newly active LP payout account are held for 72 hours. The database sets the hold at activation and refuses any change to it. A payment release is refused while it runs, both by the application at the moment of release and by the database. There is no override.

Calculation integrity

Anything that touches money — capital account rollforwards, management fees, expense allocations, performance metrics — runs through a deterministic calculation engine, never a floating-point shortcut. Every run stores a frozen snapshot of its inputs, a version, and the identities of its preparer, reviewer, and approver, so a number can always be reproduced and traced back to exactly what produced it. Amendments are reversal-based, matching the audit-trail discipline above, and outputs stay in draft until a person approves them — nothing calculated is treated as final without a human in the loop.

How AI is used

AI in NAVdryx drafts and extracts; it never calculates and never finalizes anything. Document extraction and drafting assistants produce output with source citations back to the specific record, page, or clause they came from, and every output requires human review before it is relied on. Sensitive identifiers — tax IDs, bank details, personal identifiers — are stripped by a redaction step before any request reaches an AI provider, and every prompt and output is version-controlled and logged.

Vendors and manual fallback

External services — e-signature, email, identity, and similar providers — sit behind an internal adapter interface rather than being wired directly into the product, which keeps any single vendor from becoming a structural dependency. In the same spirit, every integration ships with a manual CSV, Excel, or PDF path. That path is not a fallback bolted on for outages; it is a designed feature, because a fund accountant must always be able to finish the job even when a specific integration is unavailable.

Independent testing

Independent penetration tests are planned as launch requirements: one before the platform holds client financial data, and a second before the first client goes live. NAVdryx maintains a SOC 2 Type I readiness program as part of its standing security posture, with a defined path toward a Type II report over time. Data-retention floors are set per record type — covering securities, tax, anti-money-laundering, and privacy requirements — and are enforced as minimums: a record cannot be deleted before its floor. A setting that lets a tenant extend retention beyond a floor is not yet available.