Security

Remorant handles transaction data for financial institutions, so security is part of how the product is built. This page describes the controls that are in place today.

We list only what is implemented. We do not show certification badges we do not hold, and we answer security questionnaires and architecture questions directly during an evaluation.

The service has three parts: a web application, a scoring API and a database.

• Your systems call the scoring API over HTTPS. The API validates the request, scores it and returns a decision.
• The web application is the dashboard your team signs in to. It talks to the same API.
• Each customer is a separate tenant. Records carry a tenant identifier, and requests are scoped to the tenant of the authenticated account.

• In transit: the web application and API are served over HTTPS, with strict transport security enabled in production.
• Passwords: stored as bcrypt hashes. We cannot read them back.
• API keys: stored as SHA-256 hashes and shown once, when they are created.
• Webhooks: each delivery is signed with HMAC-SHA256 so you can verify it came from Remorant.
• Data subject requests: access, export and erasure requests are logged and handled through a dedicated workflow.

• The API authenticates each request with a signed token. Tokens expire after eight hours.
• A user can revoke all of their active sessions at once.
• Role-based permissions separate platform administrators, tenant administrators, analysts, read-only users and integration accounts.
• Sign-in and password reset endpoints are rate limited to slow down guessing attacks.
• Password reset links are single use and expire after 30 minutes.

• Each production scoring request is recorded with its decision, model version, threshold and reason codes.
• Every decision has a decision ID and an audit reference that link back to that record.
• Actions taken in the dashboard are written to an audit trail that can be filtered and exported.
• Model behaviour is monitored for drift, with alerts when input or score distributions shift.

• Requests are validated against a schema before they are processed, and request bodies are capped in size.
• Error responses return an error code and message without exposing internal details.
• A content security policy, framing protection and related browser security headers are set on responses.
• The development-only authentication bypass cannot be enabled in production. The service refuses to start if it is.
• Automated tests cover the API contract, decision logic and input validation.

If you believe you have found a security issue in Remorant, please write to hello@whizzonby.com with a description of the issue and the steps to reproduce it.

Please give us the chance to investigate and fix the issue before sharing it publicly, and do not access or change data that is not yours while testing.

The controls on this page are designed to support the security and audit expectations of regulated financial institutions. They are implemented controls, not third-party certifications.

If your review needs specific evidence, such as a completed questionnaire or an architecture walkthrough, ask us at hello@whizzonby.com and we will tell you plainly what we can provide.

If we become aware of a security incident that affects customer data, we investigate, contain it and notify the affected customers, in line with the law and with our agreements with them.

Security questions and reports go to hello@whizzonby.com. For how we handle personal information, see our Privacy Policy.