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.

Every role also has Ask Credora: plain-English questions answered by Claude through the official Exasol MCP server, logged in to Exasol as that role's own database user.

Verify it yourself#

Each claim can be checked on the live site and in one or two files.

Contents#

1. The problem
2. How Credora solves it
3. Architecture
4. Exasol at the centre
5. Role-based access, enforced by Exasol
6. Ask Credora: try these
7. Scale and measured performance
8. Key decisions and trade-offs
9. Security and data governance
10. Failure modes
11. Deploy it yourself
12. Repository layout
13. 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 · roles and AI access · 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)
       each role reads Exasol as its own user: CREDORA_ADMIN / _DATASCI / _LOANOPS / _RM

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. Role-based access, enforced by Exasol#

Access is decided by Exasol, not by the web app. Each of the four roles has its own Exasol user and database role (exasol/sql/07_security.sql). The backend runs every read for a signed-in person as that person's role user (backend/app/exa.py ROLE_USER, backend/app/routes/core.py db()); a query Exasol refuses comes back as 403 Exasol denied access for your role. Ask Credora starts the Exasol MCP server logged in as the same user (backend/app/assistant.py exasol_login()), so the AI can read exactly what the person can read, no more. Analysis, training, the CRM export and the purge run as the service user CREDORA_SVC.

Diagram: roles and AI access shows the four roles as rings of data, one Ask Credora question travelling from the login token through the topic gate and exasol_login() into Exasol as the role's own user, and what each role and its AI can and cannot do.

How the layers fit:

• Objects and columns are decided by Exasol grants. The latest-run views behind the semantic layer run with their owner's rights and are granted per role (exasol/semantic/11_latest_run_views.sql), so the RM's semantic queries never touch model features.
• Semantic SQL is routed per role by the preprocessor framework: one rule per role in exasol/extensions/10_semantic_views_module.sql. CREDORA_SVC has no rule and pays nothing.
• The RM's book (rows where RM_ID = 'RM001') is filtered by the backend on top of the CREDORA_RM grants.
• The AI cannot write. The MCP server runs with enable_write_query, enable_write_bucketfs and the preprocessor tools switched off (MCP_SETTINGS in backend/app/assistant.py).

Verified on the live site: an admin question joined VS_CIF."partner", VS_LOS."application" and VS_CBS.TXN / ACCOUNT across three databases in one statement; the same question asked as the RM was answered from V_COMPANY_MASKED only.

6. Ask Credora: try these#

Ask Credora answers from the semantic layer CREDORA_SEM.PORTFOLIO first (15 certified metrics, exasol/semantic/12_credora_model.sql), then with plain SQL where the role allows it. Each answer lists every MCP tool call with the exact SQL it ran. A one-word topic check runs before any tool use: unrelated requests (poems, recipes, "ignore your rules") are refused and never reach Exasol.

The page suggests four questions per role, each exercising a different Exasol feature:

Ask a question outside a role's grants (for example the admin's cross-database question as rm) to see Exasol, not the prompt, set the limit.

7. 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.

8. Key decisions and trade-offs#

9. 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: each role reads as its own Exasol user (section 5). Loan operations cannot read raw outside data; relationship managers read results and a masked company view, and the app limits them to their own book.
• AI inside the same boundary: Ask Credora's MCP server logs in as the signed-in role's Exasol user with writes switched off; a topic check refuses unrelated questions before any query; every SQL statement it ran is shown with the answer. Credit memos are generated inside Exasol by the CREDIT_MEMO UDF, with the API key held in CONNECTION AI_LLM.
• 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.

10. Failure modes#

11. 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.

12. 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

13. Documentation#

License#

MIT. See LICENSE.