Credora

Pre-approved corporate loan offers for Sapphire Bank, decided inside Exasol.

Built for ExaThon India 2026 · Powered by Exasol Personal.

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

Contents#

1. The problem
2. How Credora solves it
3. Architecture
4. Exasol at the centre
5. Scale and measured performance
6. Key decisions and trade-offs
7. Security and data governance
8. Failure modes
9. Deploy it yourself
10. Repository layout
11. Documentation

1. The problem#

Sapphire Bank has 1,000 corporate current-account customers, each run by 2 to 5 partners. Instead of waiting for loan applications, the bank wants to approach its best customers with a pre-approved loan offer: an amount, a rate (ROI) and a tenure, plus a negotiation limit the relationship manager can move within without going back to credit.

To decide that, a credit officer needs data that lives in six places, half inside the bank and half outside it:

Requirements

• Functional: combine all six sources per company; score credit risk with a model trained on the bank's own loan history; price an offer and a negotiation limit that still meet the bank's return hurdle; rank the portfolio; show every number with its source; let four roles work the result, from data generation to sanction.
• Non-functional: no copy of core banking leaves the bank's databases; consent-based outside data is deleted on time, with proof; each role sees only what it may see, enforced by the database; the full analysis of 1,000 companies runs in under a minute; the whole system rebuilds in any AWS account from this repo with one command.
• Out of scope: real CIBIL, GSTN or Account Aggregator connections (Credora ships faithful mocks); loan disbursement and servicing; real customer data of any kind.

2. How Credora solves it#

One call, EXECUTE SCRIPT CREDORA.RUN_ANALYSIS('<run>'), does the whole job inside Exasol in about 20 seconds:

1. Read the bank's data in place. Virtual schemas expose Oracle, MySQL and PostgreSQL as Exasol schemas. Queries are pushed down to the source; nothing is copied first.
2. Fetch the outside world. Python UDFs call the CIBIL, GSTN and Account Aggregator relays over the public internet, 16 in parallel, and stage the replies with a purge time.
3. Build features. Thirteen credit features per company: GST turnover and filing discipline, the gap between GST turnover and bank credits, balances, inflow volatility, bounces, CIBIL ranks and partner scores, other-bank balances, debt service cover.
4. Score risk. A gradient-boosted model, trained inside Exasol on the bank's past loans, gives each company a probability of default and the effect of each feature on it.
5. Price and decide. Amount, ROI and tenure as the offer; floor ROI, maximum amount and maximum tenure as the negotiation limit, where the bank's risk-adjusted return (RAROC) still meets its hurdle; Approve, Refer or Decline with reasons.
6. Rank. Exasol's PREFERRING skyline peels off the companies that are best on return, risk and size at the same time. The top 50 go to the relationship managers.
7. Hand over. The web app exports the offers to the CRM, and relationship managers negotiate inside the limit while loan operations verifies and sanctions.

Every step is logged with its row count and duration, and the web app shows each one with the SQL, Lua or Python that ran.

3. Architecture#

Diagrams: all diagrams · big picture · AWS deployment · inside Exasol · analysis flow · full design document

   Sapphire Bank (private RDS)                    Outside world (https://credora.link)
   Oracle CBS   MySQL CIF   PostgreSQL LOS        cibil.   gst.   aa.   (HTTPS relays)
      |             |             |                  |       |      |
  Oracle VS    adbc-vs-rs    adbc-vs-rs          Python SET UDFs, 16 in parallel
      \_____________|_____________/__________________|_______|______|
                                  |
               Exasol Personal on EC2 (r6i.xlarge, via the official launcher)
   virtual schemas · API UDFs · ML training and scoring · Lua orchestration · PREFERRING
   per-role users · masking · purge with proof · preprocessor framework · semantic layer
                                  |
          Web app at https://credora.loan (React + FastAPI behind Caddy, HTTPS)
     Admin · Data scientist · Loan operations · Relationship manager · Ask Credora (MCP)

4. Exasol at the centre#

Credora is assembled from Exasol's open-source building blocks, from the exasol and exasol-labs GitHub organisations, plus the bank-specific logic in this repo. docs/WHY_EXASOL.md covers each feature in depth.

5. Scale and measured performance#

The demo data set is generated, but its volumes are realistic for a mid-size corporate book.

RUN_ANALYSIS on the live deployment (one r6i.xlarge node):

The risk model reaches an AUC of about 0.75 on a hold-out set of past loans. A full data regeneration takes about 75 seconds.

6. Key decisions and trade-offs#

7. Security and data governance#

• Network: only Caddy (80, 443) is public. Exasol's ports (8563, 8443, 2581, 22) open only to admin IPs; the RDS databases sit in private subnets reachable from the VPC only.
• Least privilege in the database: loan operations cannot read raw outside data; relationship managers see only their own companies through a masked view; the AI assistant uses a read-only user.
• Secrets: generated per deployment by OpenTofu into AWS Secrets Manager; Exasol keeps API tokens in CONNECTION objects; nothing secret is in the repo.
• Consent and retention: raw CIBIL, GST and Account Aggregator replies carry a purge time. PURGE_EXPIRED deletes them on schedule and keeps the row count and a SHA-256 fingerprint as proof.
• Synthetic data only: every company, person and account is generated.

8. Failure modes#

9. Deploy it yourself#

You need an AWS account with one Route 53 hosted zone (two for the outside-world domain), the AWS CLI logged in, Docker, Node.js, Python 3.12 and the Exasol Personal launcher.

cp .env.example .env.mysite      # AWS_PROFILE, DOMAIN, optionally EXTERNAL_DOMAIN
make setup                       # Python dependencies for the deploy tool
make deploy ENV=mysite           # or: python deploy/credora.py deploy --env mysite

deploy is idempotent and builds everything in order:

1. Exasol Personal on EC2 through the official launcher, its ports limited to your IP.
2. RDS for Oracle, MySQL and PostgreSQL, the app host, S3, Secrets Manager and DNS for both domains, with OpenTofu.
3. The web app, API, mock APIs, generator, docs, video and presentation sites, with Docker Compose.
4. 1,000 companies of synthetic data.
5. In Exasol: the Rust container, both virtual schema adapters, the Oracle JDBC driver, connections, UDFs, Lua scripts, virtual schemas, roles, users, the preprocessor framework and the semantic model.
6. The first model training and analysis.

Everything local about a deployment (launcher directory, OpenTofu state, SSH keys, logs, ACCESS.md) lives in deployments/<name>/, which is gitignored. Copy it with .env.<name> to operate the same deployment from another machine. See docs/PORTING.md.

10. Repository layout#

credora/
├─ deploy/        one-command deploy tool, remote start script
├─ infra/         OpenTofu: RDS x3, app host, S3, secrets, Route 53 for both domains
├─ exasol/
│  ├─ sql/        schemas, connections, virtual schemas, security
│  ├─ udf/        Python UDFs: outside APIs, ML training and scoring, AI memo
│  ├─ lua/        RUN_ANALYSIS, TRAIN_MODEL, PURGE_EXPIRED
│  ├─ extensions/ the semantic layer as a preprocessor-framework module
│  └─ semantic/   latest-run views and the Credora semantic model
├─ db/            Sapphire Bank schemas (Oracle, MySQL, PostgreSQL) and the mock API schemas
├─ mocks/         mock CIBIL, GSTN and Account Aggregator APIs; synthetic data generator
├─ backend/       FastAPI: roles, jobs, reports, CRM export, Ask Credora
├─ frontend/      React + TypeScript
├─ sites/         docs, video, presentation and outside-world sites
├─ media/         demo video and presentation files
└─ docs/          architecture, diagrams, data model, APIs, why Exasol, porting

11. Documentation#

License#

MIT. See LICENSE.