Security and data handling
What is enforced today, and what is not yet built.
RunPayway™ is an early-stage platform. This page states what the product enforces now, names the frameworks that inform its design, and says plainly where it holds no certification. Send it to whoever runs your vendor review.
For what an institution would be adopting, where RunPayway™’s responsibility ends, what your own administrators control, and what can be established from a completed record months later, read Institutional review.
Who can reach a record
Access is resolved on the server for every request, from a validated session and a verified membership. Middleware also redirects a signed-out browser, but that is a convenience and not the control. A forged or stale cookie passes middleware and is rejected by the server-side resolution behind it.
Three roles, checked before the record is touched
Organization Administrator, Assessor, and Reviewer. Every route handler resolves the role from the session and checks it before reading or writing. A Reviewer who reaches the record-creation URL is returned to the list rather than shown a form whose submission would be refused.
One organization per record
Every read and every write filters on the owning organization taken from the validated session. It is never read from request data. A record identifier belonging to another organization does not resolve, and the response is the same not-found that a record which never existed would receive. Confirming that a record exists is itself a disclosure about another institution.
No public registration
Organizations and staff accounts are created through an administrator-controlled process. There is no sign-up form, no address to enumerate, and no default credential. A disabled account fails sign-in with the same message as an unknown address, so neither state is disclosed.
Sessions and credentials
Sessions carry a 12 hour absolute expiry and a 1 hour idle timeout, refreshed by use. Passing either ends the session. The session token exists only in an HttpOnly cookie; the database stores a SHA-256 digest of it, so a copy of the session table does not let anyone sign in. Passwords are stored as salted scrypt digests, each with its own 16-byte salt, and the plaintext is never written to the database.
What a proof request holds, and what it never learns
A proof request is a governed question — qualifying funds at or above a stated threshold — addressed to a person who does not work for you and holds no account here. The controls below exist because that person is outside both institutions, and because the least this product can hold about them is the most it should.
Your institution names the person, and nothing else about them is held
The name your administrator asserts is held in a record of its own, bound to your organization, because establishing that a person controls a financial source means comparing the name you gave against the name the source holds. Nothing further about them is stored: no email address, no telephone number, no postal address, no date of birth, and no government identifier. The authorization itself carries no identity at all, only a fingerprint of the credential that was sent and the answer that came back.
Your administrators cannot answer on someone's behalf
There is no route, no service function, and no authority rule by which an employee of the asking institution can record a person's agreement for them. The one act your institution holds is opening the question. This is enforced by the absence of the capability, not by a policy about how the capability should be used.
The link is the whole authority, and it is shown once
A person answers by holding a 256-bit credential and nothing else — no account, because requiring one would make agreement conditional on joining the product doing the measuring. It is returned at the moment it is created and only its SHA-256 is stored, so it cannot be recovered afterwards from anything RunPayway™ holds, a backup included. It permits two acts on one authorization, it expires, and it can say nothing about any other request, any other person, or any other institution.
Asking, withdrawing and addressing are separate administrator acts
Each is resolved through its own rule rather than one shared permission, so that two of them agreeing today is a fact about this release and not a synonym that has been collapsed. Reading what your institution has asked is open to its live members. Every one of these acts is appended to the same hash-linked history as the rest of the product; there is no second chain for this domain.
Nothing in this release establishes the fact, reaches a financial source, reads evidence, or issues a proof. Agreeing to be measured is not being measured. There is therefore no result to protect here, no signing key, and no recipient verification endpoint — and none of those is described anywhere on this page as though it existed.
What the product will not change after the fact
Case references can be amended so a record can be matched to the system it came from. Those three references are the only fields any operation in RunPayway™ writes to a stored record: the update path accepts them and nothing else, and the endpoint behind it rejects any other field outright.
The figures, the result, the result hash, and the methodology version are what the engine issued, and no operation in the product changes them. We state that as a property of the application rather than of the database, because it is one. There is no storage-level constraint or trigger that would stop a future write path, and no cryptographic seal. If your review needs immutability enforced below the application, RunPayway™ does not have it today.
Reopening a record does not rerun the evaluation. The stored result values, the result hash, the methodology version, and the time the result was issued remain those the engine produced. Those stored values are presented through the product’s current record interface, which changes as the product changes; what a reviewer sees is the stored record, not a preserved copy of the screen that displayed it.
A completed record downloads as a governed file your organization keeps. It is assembled by the same reader that renders the record on screen, so the file and the page cannot describe one record differently. Your institution can also produce a portable copy to hand to an examiner or a committee who has no account here; they present it back and are told whether it still matches what RunPayway™ recorded when it was produced. That check is a comparison against our stored digest, answered by asking RunPayway™. It is not a digital signature and is not verifiable offline against a public key.
Identifiers that appear in a URL are non-guessable and carry no sequence, so one organization’s record cannot be reached by walking an identifier from another.
Frameworks we design against
We name the frameworks that inform our control design, and we state where we stand against each one. We would rather you learn this here than in week six of a pilot.
SOC 2 Trust Services Criteria
Used as a reference for control design across security, availability, processing integrity, confidentiality, and privacy.
Not certified. No audit has been performed.
ISO 27001
Used as a reference for risk assessment, access control, and continuous improvement.
Not certified. No information security management system has been formally assessed.
If your vendor risk process requires a completed SOC 2 Type II report, RunPayway™ does not have one today. Raise it in the fit conversation and we will tell you what exists and what would have to be built.
Not built yet
A capability list is only useful if its absences are in it. The following are not implemented, are not on this page as features, and are scoped with pilot partners rather than offered from a page:
Single sign-on
There is no SAML, OIDC, or SCIM integration. Staff sign in with an administrator-provisioned account.
Partner API and webhooks
An institution can issue a read-only credential so a system it operates collects its own completed records. That is the whole of it: there is no third-party integration surface, no write path, and no outbound webhook or event delivery of any kind.
Core and origination system connectors
RunPayway™ is a web application your authorized staff sign in to. A pilot requires no change to your core or your loan origination system.
Read-access logging
Consequential acts are recorded, and an administrator can ask whether the institution’s recorded history still holds. Nothing records who opened or read a record, so the history answers what was done and never who looked.
Retention and deletion schedules
No retention period, deletion schedule, or automatic disposal is enforced in the product. If your review requires one, it is scoped in the fit conversation rather than offered from this page.
Proof issuance, signing and recipient verification
A proof can be requested and a person can agree to it. Nothing establishes the fact, produces a result, signs anything, or offers a recipient somewhere to check a proof against. No signing key is created, held, or rotated here, no credential of that kind is issued, and there is no endpoint for a third party to call.
Storage-level immutability
A stored result is protected by the application, which exposes no operation that changes it. There is no database constraint, trigger, write-once store, or cryptographic seal enforcing that below the application.
Ask us the hard questions early
The fit conversation is where scope, boundaries, and price are established in writing. Bring your vendor risk requirements to it.