Credora

Credora helps a bank lend to its own business customers before they ask. For every corporate customer of Sapphire Bank it decides whether to make a pre-approved loan offer, sets the amount, rate and tenure, and sets how far the relationship manager may negotiate. All of the analysis runs inside Exasol Personal, where the bank's data already meets.

It is live. The links below are the real deployment. The demo video is published on its page when ready.

Sign in with one click on the login page, or use a demo login. All data is synthetic, so the passwords are public.

• admin / Demo@123 is the bank manager, who approves models and policy.
• datasci / Demo@123 is the data scientist, who runs the analysis and publishes it.
• loanops / Demo@123 is loan operations, who assigns companies to relationship managers.
• rm / Demo@123 is Subhashree Mohanty (RM001), a relationship manager who sees only her own companies.

Submission at a glance#

The problem#

Sapphire Bank's credit team can't make pre-approved offers to the corporate customers it already serves, because the evidence sits in six separate systems and is gathered by hand, one company at a time. If this worked, every corporate customer would be decided in one run, and the relationship manager would call with an offer and a negotiation limit already set.

Banks already hold most of what they need to lend to their existing business customers. Transactions sit in core banking, partner and KYC details in the customer master, and each company's credit need on file in loan origination. Credit bureau, GST and Account Aggregator data can be fetched by API, with the customer's consent.

The trouble is that this data lives in separate systems. A credit team has to gather it by hand, score the risk and price each offer one customer at a time, so good customers wait weeks and some are never approached. Copying everything into yet another system adds cost, delay and data-protection risk.

Credora answers one question for every corporate customer, in one run. Should the bank offer this company a loan, how much, at what rate and for how long, and how far can the relationship manager negotiate? It answers it where the data already is, and each person sees only what their role allows.

The solution#

Sapphire Bank has a large book of corporate current-account customers and wants to approach the best of them with a pre-approved offer. Each offer has an amount, a rate and a tenure, plus a negotiation limit the relationship manager can move within. The data for that sits in the bank's Oracle, MySQL and PostgreSQL databases (including each company's credit need on file) and in 3rd party data via API from CIBIL, GSTN and the Account Aggregator. One call, EXECUTE SCRIPT CREDORA.RUN_ANALYSIS('<run>'), reads all six sources in place, scores risk with models trained in Exasol and prices and ranks the companies analysed in 17.5 s.

Credora does all of this inside Exasol Personal, where the data already meets, so the bank can approach its best customers first with a ready offer. The data scientist runs the analysis and publishes it. Loan operations assigns the companies to relationship managers, and each manager negotiates inside the limit and logs the loan status. The admin approves model activations and policy changes. In every role, Ask Credora answers plain-English questions with Claude through the official Exasol MCP server.

What changes for the bank#

On the published run R20261031-1923, Credora analysed 1,000 companies and decided 530 APPROVE, 202 REFER and 268 DECLINE. The pre-approved offers to the 530 approved companies total ₹1,168.9 crore, against a credit need on file of ₹1,252.3 crore, with negotiation room up to ₹1,414.2 crore. The Top 50 alone carry ₹258.7 crore of offers at an average rate of 10.82% and a RAROC of 21.2%. A run takes 17.5 s, so the bank can decide its whole corporate book again after every policy change or data refresh. The relationship manager negotiates inside the limit Exasol set for each company. A deal within the limit needs no credit committee round trip, and only a deal beyond it is escalated to loan operations.

Exasol features used#

Credora started on the Exasol Personal Local Starter Kit (exakit 0.2.3, with the Exasol MCP server 2.3.0, exapump 0.13.1 and pyexasol). It was then deployed on AWS with the Exasol Personal launcher 2.3.0, running Exasol 2026.1.0 on an r6i.xlarge.

Each feature, with its code and the reason for it, is in docs/WHY_EXASOL.md.

Roles, enforced by Exasol#

Every app role reads Exasol as its own database user. The backend runs each screen's queries as that user. Ask Credora starts the MCP server logged in as the person's own AI user (CREDORA_ADMIN_AI, CREDORA_DATASCI_AI, CREDORA_LOANOPS_AI or CREDORA_RM_AI), which holds the same role and sits in the CREDORA_AI consumer group with a 60 s statement limit and 2 GiB of temporary memory. The admin's AI user has no dictionary access, so the AI cannot read the audit log. A role with no AI password gets a 503, with no fallback user. When Exasol refuses a query, the screen shows 403 Exasol denied access for your role. Analysis, training and the purge run as the service user CREDORA_SVC.

The RM logs the loan status one step at a time, from Contacted to Disbursed. Loan taken needs terms agreed within the negotiation limits or sanctioned by loan operations (docs/API.md).

The V_RM_* views join CREDORA.RM_ASSIGNMENT on the logged-in Exasol user (an AI session user <person>_AI counts as its person), and R_RM has no grant on the result tables. Signed in to Exasol as CREDORA_RM, V_RM_DECISIONS returns her 25 companies and SELECT * FROM CREDORA.DECISIONS fails with "insufficient privileges". A prompt can't widen that, because the limit lives in the database. The control room panel "Row-level security, proven by Exasol" (GET /api/admin/rls-proof) runs that SELECT as CREDORA_RM, as her AI user CREDORA_RM_AI and as a second manager, CREDORA_RM002, and shows each result and each refusal.

Verify it yourself#

Every feature below can be tried on https://credora.loan and found in the code.

About the AUC. The champion scores AUC 0.756 (Gini 0.512) and the challenger scorecard 0.769 (Gini 0.538), both on the same hold-out of the 5,000 past loans, which have a 7.5% default rate. The numbers sit near the ceiling the synthetic data allows. The generator (risk.py) draws each default from Bernoulli(sigmoid(-3.05 + 1.25 z)), where z is the company's hidden risk, so even a model that knew z exactly would score about 0.78. The scorecard beats the trees because that relationship is logistic and linear in z, and 5,000 loans favour the simpler model.

Setup and reproduction#

Try it in two minutes, no AWS#

The web app runs on its own with synthetic fixtures in the browser, so you can click through every screen and every role without a backend or a database.

cd frontend
npm install
npm run dev:fixtures

Open http://localhost:5173. Any password works, the demo-user buttons sign in at once, and ?as=admin, ?as=datasci, ?as=loanops or ?as=rm on any URL signs in as that role. Fixture state lives in the browser's localStorage under credora.fixtures.v2, so clear it to start over. The fixtures follow the API and the decision logic in the browser. Only the live site runs on Exasol.

Deploy it to your own AWS account#

Everything runs from your own machine against your own AWS account. Nothing in the code is tied to an account or a domain.

1. Install the Exasol Personal Local Starter Kit, following its README. It brings the exasol launcher from exasol/exasol-personal, uv, pyexasol, exapump and the Exasol MCP server. Check it with exakit version (Credora was built with 0.2.3) and exasol version.
2. Install the AWS CLI v2, Docker, Python 3.12, Node.js 22 and Git.
3. Log in to AWS, and have a Route 53 hosted zone in that account. The default sizes need 6 vCPUs of on-demand EC2. bash aws configure --profile mysite aws sts get-caller-identity --profile mysite
4. Clone the repo and install the deploy tool. bash git clone https://github.com/anamika-iit-kgp/credora.git cd credora make setup # or: uv venv deploy/.venv && uv pip install -p deploy/.venv -r deploy/requirements.txt
5. Copy .env.example to .env.mysite and fill it in. The name after .env. is the deployment name.

6. Deploy, then write every URL, login and password to deployments/mysite/ACCESS.md. bash python deploy/credora.py deploy --env mysite python deploy/credora.py access --env mysite

deploy is idempotent. It installs Exasol through the launcher, creates the RDS databases, app host and DNS with OpenTofu, starts the containers, generates 1,000 companies and sets up every Exasol object. Database and API passwords are generated into AWS Secrets Manager. Other commands (status, infra, ship, exasol, generate, destroy) and moving a deployment to another machine are in docs/PORTING.md.

Cost and time#

Roughly $0.46 an hour for the instances, about $11 a day, plus small charges for gp3 storage, the Elastic IP, Route 53 and S3. Prices are from the AWS Price List API on 1 November 2026. A full deploy takes about 45 minutes, most of it waiting for RDS and the Exasol launcher. python deploy/credora.py destroy --env mysite removes everything the deployment created.

Running pieces locally on the starter kit#

These run on a laptop without AWS and without Exasol.

• The mock APIs and the generator. docker compose -f mocks/docker-compose.dev.yml up -d --build, then curl -X POST localhost:8100/generate -H 'content-type: application/json' -d '{"seed": 42}' (mocks/README.md).
• The backend tests, which include the atomic job guard, the busy pool mapped to 503, the overview count cache and the audit mask. pip install -r backend/requirements-dev.txt, then python -m pytest -q in backend/.
• The UDF tests, which run the deployed UDF code in exasol/udf-mock-python. They cover both trainers and the SHA-256 they emit, PD_SCORE refusing a mismatched hash, MODEL_FILE_SHA256, ANOMALY_FLAG and the retry helper of all four fetch UDFs. pip install -r tests/udf/requirements.txt, then python -m pytest -q in tests/udf/.
• The generator tests. python -m pytest -q tests in mocks/generator/.
• The web app on fixtures, as above.

These need a local Exasol from the starter kit.

• The SQL, Lua and UDF files in exasol/. deploy/sql_runner.py is a small module. run_file(connection, path, values) fills the ${VAR} placeholders, splits the file into statements (a CREATE SCRIPT body ends at a line holding /) and runs them over pyexasol.
• The Python UDFs, in the kit's built-in Python 3 container. The API UDFs need the mock APIs above reachable from Exasol, and the ML UDFs need a BucketFS bucket for the model files.

These need AWS.

• deploy/exasol_setup.py uploads the Rust container, the adapters and the drivers to BucketFS over SSH to the Exasol node, and needs the node's private IP.
• The virtual schemas VS_CBS, VS_CIF and VS_LOS read the three RDS databases, so they exist only on a deployment.

The tests also run in GitHub Actions on every push, and CONTRIBUTING.md lists the commands.

Known limitations#

• All data is synthetic, from the generator, and the models learn synthetic labels. The AUC says more about the generator than about real credit risk.
• Exasol runs on one node. Nothing has been measured on a cluster.
• There is one demo relationship manager login, rm as RM001, plus one extra manager user in Exasol, CREDORA_RM002, used by the row-level security proof.
• The offer carries no KFS or APR fields.

Troubleshooting#

• VS_CBS fails with an unknown-host error for the RDS endpoint, often after an Exasol restart. The java-17 script language container has no /etc/resolv.conf or /etc/hosts. Run exasol/hotfix/slc_dns_fix.sh on the node over SSH. It links both files to the node's /conf copies inside the container. Run it again after every Exasol restart.
• A deploy that stopped part way can be run again. deploy is idempotent.
• Exasol or SSH refuses your new IP. python deploy/credora.py allow-ip --env mysite opens them to this machine.
• Ask Credora answers 503. The MCP server process failed. Ask again, because each question starts a fresh process.
• A purge run shows SKIPPED. An analysis was in progress, and the next scheduled run purges.

Data sources, licences, APIs and third-party tools#

All data is synthetic and made by Credora's own generator (mocks/generator), with seed 2026 on the live site. The live data set starts at 1,000 companies, and the admin can add more with one click. Sapphire Bank, its companies, their partners, accounts, transactions, GST returns and credit reports are invented. No real person, company or bank record is used. The generator can replace the data set or add more companies with unique names, PANs, GSTINs and account numbers.

The three mock APIs are written for this project (mocks/). They follow the shape of the real services, but no real CIBIL, GSTN or Account Aggregator API is called, and no credentials for them are needed. Their contracts are in docs/API.md.

Ask Credora and the credit memos call Claude through the Anthropic API (model claude-sonnet-5-5), under Anthropic's commercial terms. Amazon Bedrock can be used instead. Without an AI key the rest of the app works.

The third-party tools and their licences are below.

Exasol, Oracle, MySQL, PostgreSQL and other names and logos belong to their owners and appear only to identify the systems used. Credora's own code is MIT licensed.

Demo video and supporting materials#

The docs, presentation and video sites each show a simple view count, also listed next to their links in the app. Only one number per site is stored, nothing about visitors. The video page plays whatever file a video.json next to it points to, so the video can be published without a code change.

Diagrams#

The full design, with failure modes and trade-offs, is in docs/architecture.html.

Repository layout#

exasol/     SQL, Python UDFs, Lua scripts, preprocessor modules and the semantic model
backend/    FastAPI with roles, jobs, Ask Credora and the Exasol audit
frontend/   React and TypeScript, with Explain mode
mocks/      mock CIBIL, GSTN and Account Aggregator APIs and the data generator
deploy/     the one-command deploy tool, with infra/ (OpenTofu) beside it
docs/       architecture, diagrams, glossary, data model, APIs, porting

Documentation#

Built with Exasol open source, thank you#

Every project below runs in the live deployment or in CI. Thank you to the Exasol team and to everyone who contributes to them.

About, contributing and contact#

Credora is an ExaThon India 2026 project, a bank's pre-approved corporate lending, decided inside Exasol Personal. It was built on the Exasol Personal Local Starter Kit and deployed on AWS. The live deployment runs in my own AWS account, on the domains credora.loan and credora.link, which I registered for this project. This is version 1.1.0, see CHANGELOG.md.

Contributions are welcome, see CONTRIBUTING.md. Security reports go through SECURITY.md, and the code of conduct is short. To build on Credora, adapt it for your bank, or buy or license it, raise an issue and I will get in touch.

Project by Anamika, Product Manager @ Equitas Small Finance Bank. Sapphire Bank is fictional, and all data is synthetic.

License#

MIT. See LICENSE.