Credorafor Sapphire Bank

Pre-approved corporate credit, decided inside Exasol.

An ExaThon India 2026 project. A bank's pre-approved corporate lending, decided inside Exasol Personal, built on the Exasol Personal Local Starter Kit and deployed on AWS. Sapphire Bank is fictional and all data is synthetic.

Anamika · Product Manager @ Equitas Small Finance Bank

credora.loan the app docs.credora.loan credora.link 3rd party data via API

Built for ExaThon India 2026 · Powered by Exasol

Personal

The bank already holds the data. Offers are still slow and manual.

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.

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. Sapphire Bank has a large book of corporate current-account customers, and it already holds most of what it needs to lend to them. Transactions sit in Oracle core banking, partners and KYC in the MySQL customer master, the credit need on file and five thousand past loans in PostgreSQL. The rest is 3rd party data from CIBIL, GST returns and the Account Aggregator. Today a credit officer visits these one company at a time. Press next. Credora reads all six at once, inside one Exasol call, in eighteen seconds for all thousand companies.

Analyse the customers we have, then offer them credit first.

Every corporate customerexisting current-account customers, 2 to 5 partners each

Analysed in Exasolbank data, bureau, GST and AA data, risk model, policy

Pre-approved offeramount, ROI (rate) and tenure, plus a negotiation limit

RM calls the customerand negotiates inside the limit, no trip back to credit

PDprobability of default

How likely the company is not to repay, from a model trained on the bank's own past loans. Graded A1 (under 1%) to D (12% and above).

RAROCrisk-adjusted return

(Rate − cost of funds − operating cost − PD × loss given default) ÷ capital held. Every offer must clear the 15% hurdle.

DSCRdebt service coverage

Cash the company generates ÷ what the loan costs it each year. At least 1.25 for the offer, 1.10 at the negotiation limit.

GSTgoods and services tax

Monthly sales each company files with the tax network, GSTN, for 2 to 10 years per company. Late filings and a gap to bank credits are warning signs.

CIBILIndia's credit bureau

A score for every partner and a commercial rank (CMR) for every company. A partner below 600 or a CMR of 9 or worse means no offer.

AAAccount Aggregator

With the customer's consent, the partners' accounts at other banks. The consent expires, so Exasol purges the data on time, with proof.

What changes for the bank.

The published run R20261102-1037 on 1,000 companies. Every figure below is read from Exasol, from that run.

₹1,065.4crore

of pre-approved offers to 531 approved companies, against a credit need on file of ₹1,156.6 crore

₹1,273.4crore

is the top of the negotiation room, the limits Exasol set per company for the relationship managers

531· 184 · 285

APPROVE, REFER and DECLINE, decided in one call, each with its reasons

₹189.3crore

in the Top 50, at an average rate of 11.0% and a RAROC of 22.7%

s

per run, so the whole book is decided again after every policy change or data refresh

0round trips

to a credit committee for a deal inside the limit. The relationship manager negotiates within it, and only a deal beyond it goes to loan operations

What does the bank get? On the published run, Exasol decided a thousand companies. Five hundred and thirty-one are approved, one hundred and eighty-four referred to a person, two hundred and eighty-five declined. The pre-approved offers to the approved companies total one thousand and sixty-five crore rupees, against a credit need on file of eleven hundred and fifty-seven crore, with negotiation room up to twelve hundred and seventy-three crore. The top fifty alone carry one hundred and eighty-nine crore at an average rate of eleven percent and a RAROC of twenty-two point seven percent. A run takes eighteen seconds, so the bank can decide the whole book again after every policy change. And the relationship manager negotiates inside the limit Exasol set, so a deal within it needs no credit committee round trip.

Everything meets in Exasol, and leaves as a decision.

Bank data is read in place, 3rd party data is fetched via API by UDFs, and every person and the AI read results as their own Exasol user.

StoreCompute in ExasolOrchestration, AISecurity3rd party APIPeople, web

One engine does seven jobs, and the data never leaves it.

Exasol Personal used to the full, with open-source extensions from both GitHub organisations, exasol and exasol-labs.

Virtual schemas push the work down. Nothing is copied.

Feature step 7 aggregates core banking by account and month. Exasol hands the join, the filter and the GROUP BY to Oracle.

-- RUN_ANALYSIS, step 7 INSERT INTO CREDORA_STAGE.CA_MONTHLY SELECT t.ACCOUNT_NO, a.OWNER_ID, TRUNC(t.TXN_DATE, 'MM') MON, SUM(CASE WHEN t.DR_CR = 'C' THEN t.AMOUNT ELSE 0 END), ... COUNT(*) N FROM VS_CBS.TXN t JOIN VS_CBS.ACCOUNT a ON a.ACCOUNT_NO = t.ACCOUNT_NO WHERE a.ACCT_TYPE = 'CA' GROUP BY t.ACCOUNT_NO, a.OWNER_ID, TRUNC(t.TXN_DATE, 'MM')

Monthly totals per account come back. The ~850,000 transactions stay in Oracle, and the bank keeps one system of record.

Python UDFs fetch 3rd party data via API, in 16 batches.

A SET script groups the keys into 16 buckets by the first hex digit of an MD5 hash. Exasol runs one UDF instance per bucket, 4 at a time on the node's 4 cores, and each call makes 3 attempts before it fails naming the service.

One Lua call runs the whole analysis, step by logged step.

EXECUTE SCRIPT CREDORA.RUN_ANALYSIS('<run>') commits after every step, so the web app can watch the run as it happens.

Measured on the live deployment for 1,000 companies, on one r6i.xlarge node.

CREDORA.RUN_LOG

STEP STATUS ROWS_OUT MS

A failed step is logged with its error and stops the run. The last published run stays visible in the app.

The models are trained, stored and scored inside Exasol.

Past loans are read live from PostgreSQL. Two models train on the same loans and the same hold-out. Only the active one decides.

Machine learning never leaves the database. TRAIN_PD reads five thousand past loans live from PostgreSQL through VS_LOS, trains gradient-boosted trees with monotonic credit constraints, measures them on a hold-out, and writes the pickle to BucketFS and a row to MODEL_REGISTRY, with AUC 0.728. TRAIN_SCORECARD trains a logistic regression challenger on the same loans and the same hold-out, with AUC 0.798. Both numbers sit near the ceiling the synthetic data allows. The generator draws each default from a logistic curve over the company's hidden risk, so even a model that knew that risk exactly would score about 0.78. The scorecard beats the trees because that relationship is logistic and linear, and five thousand loans favour the simpler model. PD_SCORE checks the file's SHA-256 against MODEL_REGISTRY, loads the active pickle and scores a thousand companies in about two seconds. Next, an Isolation Forest flagged 30 unusual companies, and 4 that would have been approved were referred to a person instead. The challenger shadow-scores every run. It would change 713 grades and 62 decisions. Next, it decides nothing until the admin approves activation.

PREFERRING ranks on three goals at once, with no weights.

The skyline is every approved company that no other beats on return, risk and amount together. Peel it off, take the next skyline, until 50 are ranked.

UPDATE CREDORA.DECISIONS SET SKYLINE_LAYER = :l WHERE APP_ID IN ( SELECT APP_ID FROM CREDORA.DECISIONS WHERE DECISION = 'APPROVE' AND SKYLINE_LAYER IS NULL PREFERRING HIGH RAROC_OFFER PLUS LOW PD PLUS HIGH OFFER_AMOUNT)

On the measured run two layers held 63 companies by the time 50 were reached, in 0.03 s. The best 50 approved go to the relationship managers.

One certified definition serves the app, the analyst and the AI.

CREDORA_SEM.PORTFOLIO holds certified metrics. The SQL preprocessor compiles semantic queries per role, inside Exasol.

METRIC approval_rate AS approved_companies / NULLIF(companies_analysed, 0) ON ENTITY decision FORMAT 'percentage' DISPLAY 'Approval rate' SYNONYMS ('approval ratio', 'hit rate') RATIO PUBLIC CERTIFIED

Exasol, not the app, decides who sees what.

Four people, four Exasol users, and an AI user for each with the same role. A relationship manager reads only the V_RM_* views, which return the companies assigned to CURRENT_USER.

-- signed in to Exasol as CREDORA_RM (role R_RM)

CREDORA_RM> SELECT * FROM CREDORA.DECISIONS;

insufficient privileges

CREDORA_RM> SELECT * FROM CREDORA.V_RM_DECISIONS;

rows, the companies assigned to

CREDORA_RM, from published runs

CREATE VIEW CREDORA.V_RM_DECISIONS AS SELECT d.* FROM CREDORA.DECISIONS d JOIN CREDORA.RM_ASSIGNMENT a ON a.CIF_ID = d.CIF_ID AND a.EXA_USER = CURRENT_USER JOIN CREDORA.RUN_PUBLISH p ON p.RUN_ID = d.RUN_ID;

The view runs with its owner's rights, so R_RM needs no grant on the tables underneath. A second manager, CREDORA_RM002, and the RM's AI user CREDORA_RM_AI run the same SELECT in the control room's proof panel. With one Exasol user per RM the views work unchanged.

Ask Credora logs in as you, so the AI cannot read more than you.

Claude reaches Exasol only through the official Exasol MCP server (exasol/mcp-server), started for each question on the app host as the signed-in person's own AI user, which holds the same role and sits in a low-priority consumer group.

Ask Credora is plain-English questions over the analysis. Watch the role travel. In step one the question arrives with the login token, here as the RM. In two and three a topic gate asks Claude, with no tools, whether this is about Credora, and anything else is refused before Exasol is touched. In four and five exasol_login maps the role to the person's AI user, and the backend starts the official Exasol MCP server, from the exasol organisation, as CREDORA_RM_AI with writes switched off. That user holds the RM's role and sits in the CREDORA_AI consumer group, with a sixty second limit and two gigabytes of memory, so the AI cannot starve the analysis. In six to nine Claude picks tools and writes SQL, and Exasol checks the RM's grants on every statement. In ten to twelve the answer comes back with every SQL statement it ran. A jailbroken prompt still cannot read more than the person who signed in.

From a published run to a disbursed loan, in four roles.

Each hand-off is a row in Exasol or the CRM, so admin, data scientist and loan operations can track every company.

Started on the starter kit, deployed to AWS with one command.

Before AWS, on a laptopExasol Personal Local Starter Kit (exakit 0.2.3) with local Exasol, MCP setup, exapump, pyexasol

$ python deploy/credora.py deploy --env <name>

Exasol on EC2, launcher 2.3.0

RDS ×3, app host, S3, DNS (OpenTofu)

App, mocks, sites (Compose)

1,000 synthetic companies

SLC, adapters, UDFs, Lua, roles, semantics

First training and analysis

Realistic volumes for a large book of corporate customers.

The data is synthetic, but the volumes are not small. Rows per source on a log scale, and what one run costs.

1k10k100k1M

s

the full analysis of 1,000 companies, 13 steps, one Exasol call

AUC of the champion. The challenger scorecard reaches

16

batches of keys per 3rd party fetch, which Exasol runs 4 at a time on the node's 4 cores

companies flagged by the Isolation Forest, and approvals became referrals

~75s

to regenerate all the synthetic data, with 1,000 companies, ~3,500 partners, every source rebuilt consistently. Semantic routing adds ~4 ms per statement.

The same run at 1,000, 10,000 and 50,000 companies.

Measured on the live single node, nothing tuned between runs. Figures from RUN_LOG and EXA_DBA_AUDIT_SQL.

17.4s

1,000 companies. 13 steps, peak temp RAM 425 MiB

67.7s

10,000 companies, 8.2 million transactions grouped in Oracle, peak temp RAM 625 MiB

320s

50,000 companies, 40.7 million transactions, 3.6 million GST filings, peak temp RAM 1.3 GiB

56s

features at 50,000. Oracle groups 40.7 million rows per account and month and only the monthly totals return

9s

to score 50,000 companies in the Python UDF, then 0.7 s to decide and 0.1 s for the PREFERRING skyline

171s

of the 320 s is the Account Aggregator fetch, 287,633 partner accounts from one small mock container. The 3rd party APIs set the clock, not Exasol

Narrow doors, and failures that stay contained.

Network

Only 80 and 443 are public. Exasol's ports open to admin IPs only, and RDS sits in private subnets.

Database grants

A user per role. A refused query reaches the app as 403 Exasol denied access for your role.

AI in the same boundary

MCP writes off, an AI user per person in a low-priority consumer group, a topic gate before any query, every SQL statement shown with the answer.

Secrets

Generated per deployment into Secrets Manager. API tokens live in CONNECTION objects. None in the repo.

Consent and retention

3rd party replies carry a purge time. PURGE_EXPIRED deletes them and keeps a SHA-256 proof per 1,000-row chunk.

If this fails	What happens	Recovery
A bank database	That step fails and stays in RUN_LOG with its error, and the last published run stays visible	Re-run when it is back
A 3rd party API	The UDF makes 3 attempts, then the step fails naming the service, stays in RUN_LOG, and nothing half-done is published	Re-run, the relays are stateless
A preprocessor module	The framework skips it (fail-open), and plain SQL keeps working	Fix or remove its rule
The Exasol node	The app shows the last results it can reach, and analysis and AI pause	Restart, and `deploy` recreates objects
The app host	The site is down, but Exasol and the databases are unaffected	`credora.py ship`
The MCP server	Ask Credora returns 503, and the rest of the app works	Ask again for a fresh process
A question outside grants	Exasol refuses, and Claude says the role cannot see it	None, this is access control working

Every screen in the demo proves an Exasol feature.

Explain mode shows it live, with an Exasol console showing the SQL behind each screen, an ⓘ glossary, and a control room.

Built with Exasol open source. Thank you.

Every project below runs in the live deployment, from both GitHub organisations, exasol and exasol-labs. Thank you to the Exasol team and the contributors.

What I learnt about Exasol Personal.

Six things the build taught me. Each one is now in the code or the docs.

Pushdown is worth checking function by function

The Oracle adapter does not push TRUNC(date, 'MM'), so step 7 groups by TO_CHAR(date, 'YYYY-MM'). That took the run from 24.7 s to 17.5 s.

EXPLAIN VIRTUAL makes pushdown provable

The Sources screen shows the SQL each database receives, so the claim is Exasol's own. It is also how the TRUNC gap was found.

The java-17 container loses DNS after a restart

It has no /etc/resolv.conf or /etc/hosts. exasol/hotfix/slc_dns_fix.sh links both to the node's /conf files again after every Exasol restart.

LISTAGG stops at 2,000,000 characters

One run's GST rows are more than that, so the purge fingerprint is built per 1,000-row chunk, and the proof is the hash of the chunk hashes.

The MCP server can log in as any user

So the AI gets the person's own rights and nothing more. A prompt cannot widen what Exasol grants.

Consumer groups are per user

So the AI got its own users, one per person with the same role, in a low-priority group with a 60 s limit and 2 GiB of memory.

Six things I learnt about Exasol Personal while building this. First, pushdown is worth checking function by function. The Oracle adapter does not push TRUNC of a date to the month, so step seven groups by TO_CHAR instead, and the run went from twenty-four point seven seconds to seventeen and a half. Second, EXPLAIN VIRTUAL makes pushdown provable, and it is how that gap was found. Third, the java-17 script language container loses DNS after an Exasol restart, and a small hotfix script re-adds the resolv.conf links. Fourth, LISTAGG stops at two million characters, so the purge fingerprints are chunked. Fifth, the MCP server can log in as any user, so the AI gets exactly the person's rights. Sixth, consumer groups are per user, so the AI got its own users. All six are in the code and the docs.