Technology
The rules are in the database, not in the application.
This is the single most consequential decision in the platform, and it is the one worth your architects’ attention.
Why that distinction matters
An application check answers the question “did we remember, here?” — and that question accumulates with every new endpoint, every script, every future integration, every engineer who joins.
A database constraint answers “is this possible at all?”, once. It covers the code path nobody has written yet.
So the things that must never happen are enforced where the data lives. A release with one signature is not discouraged; it cannot be created. A hard delete is not logged; it is refused.
What is enforced this way
- Nothing is ever hard-deleted, on any business table
- The signer of an attestation comes from the authenticated session, never from the request
- The ledger refuses updates — a correction is a reversing entry
- An agreed scope cannot be edited; a change creates a new version
- A withdrawn permission stops conferring access, and the withdrawal stays visible
- Automated agents cannot sign, authorize a release, or resolve a dispute
One gate, every caller
It is not a rule if something can go around it
A check written inside a handler protects that handler. The next endpoint, the partner integration, the batch import, the agent — each is a new place to remember.
A constraint in the database is not a place to remember. It is the shape of what can exist.
This is also why Renny can say what its automation cannot do rather than what it is instructed not to do. An agent that tries to sign an attestation does not get a warning; it gets a rejected write.
Integration
A standard API integration with the systems you already run
You keep your origination system, your servicing system, your payment rails, and your decisioning. Renny is a step in your process, not a replacement for it.
What your systems exchange
- One call to create the project when a loan is approved
- A notification to your systems the moment a release is authorized, carrying the reference and the evidence behind it
- One call back to record that you disbursed, with your own payment reference
- Read access to everything about your own book, for your reporting and your data warehouse
Notifications are signed, retried, and every delivery is recorded, so a missed message is visible rather than silent.
Credentials and scope
- Your integration credential reaches your own programs and nothing outside them
- Separate read-only credentials for reporting and analytics, with no ability to change anything
- Every call is attributed and recorded, including which credential made it
- Credentials can be revoked immediately, and revocation is visible in the record
A read-only credential is refused on every state-changing request before it reaches any handler — not by convention, by design.
Automation
Agents assist. People decide.
Renny is built so that automation uses the same audited surface a person uses, in the same order: forms first, then an API, then agents on top of that API. Nothing gets a private back door.
- An agent has its own identity and its own scoped credential, and appears in the record as itself — never as the person who asked
- Read-only by default; every state-changing request is refused before it reaches a handler
- Where a judgment is required, an agent proposes and a person decides
- A proposal cannot be edited after it is raised, and an automated account cannot approve one
Three things automation may never do
- Sign an attestation
- Authorize a release
- Resolve a dispute
Those are the acts these consent orders are about, so they stay with an accountable person. The refusal is enforced in the database rather than in a route guard — which means it also covers an endpoint nobody has written yet.
How it runs
Boring on purpose
Managed cloud
Containerized application on managed infrastructure, with a managed PostgreSQL database behind a network firewall.
Infrastructure as code
Every environment is defined in version control and reproducible, not configured by hand.
Rehearsed migrations
Every schema change is replayed against a clean database in the pipeline before it can reach an environment.
Gated deploys
A build cannot ship unless the platform’s guarantees are re-proven against a real database, every time.
The guarantees are tested, not asserted
Each protected behavior has a test that attempts the forbidden thing and requires the database to refuse it. A check that has only ever passed has not been tested — it has been assumed — so each one has also been observed failing on a real defect and passing on its fix.
Bring your architects.
We will walk your technical team through the data model, the controls, and the integration, and answer the questions your security review is going to ask anyway.