deBunq
deBunq debunks every payment request before you pay.
Inspiration
Phishing is no longer just a strange email with a bad link.
It can look like a real invoice. It can arrive as a PDF from a company you know. It can be a screenshot of a payment reminder. It can even be a voice note from someone pretending to be your child, friend, or colleague.
That is what makes modern payment scams dangerous.
The user is not always hacked. They are convinced to make the payment themselves.
A fake invoice can swap the IBAN. A phishing email can create urgency. A voice note can pressure someone to send money quickly. Once the user presses pay, the transfer can look legitimate from the bank side.
Dutch banks lose hundreds of millions of euros every year to authorised push-payment fraud: fake invoices with a swapped IBAN, "Hi mom, I lost my phone, send €450 urgent" voice notes, and phishing emails that mimic KPN, the Belastingdienst, or AON Student Insurance.
That means the safest moment to intervene is before the user confirms the payment.
We built deBunq for that moment.
deBunq is a phishing and scam shield for bunq. It checks whether a payment request can be trusted before money leaves the account. It extracts the important details, scores the risk, flags suspicious signals, and either blocks the action or prepares a safe bunq next step.
What it does
deBunq analyzes payment requests for phishing and scam risk.
A user can paste text, upload a PDF, upload an image, upload an audio file, or take a live picture of a payment request.
The request can be a phishing email, fake invoice, suspicious voice note, bill, fine, or payment reminder.
The app extracts the important payment details:
- Amount
- Due date
- Issuer
- Beneficiary
- IBAN
- Invoice number
- Payment reference
- Payment mode
It then checks whether the request is trustworthy.
deBunq looks for signs like urgent language, impersonation, secrecy requests, suspicious links, missing references, unclear payment instructions, and changed bank details.
The app gives the request a TrustScore.
If the request looks unsafe, the bunq action is blocked.
If the request looks legitimate, deBunq prepares the payment or scheduled payment for review.
No payment is sent automatically. The user stays in control.
How we built it
We built the frontend with Next.js, React, TypeScript, and Tailwind CSS.
The interface is inspired by the bunq mobile app. It uses a dark theme, colorful cards, mobile navigation, and clear action buttons.
The main page is the Inbox. This is where the user uploads a document, pastes an email, takes a picture, or analyzes a suspicious request.
The backend is built with FastAPI and Python.
The frontend sends the uploaded file or pasted text to the backend. The backend processes the input and returns structured payment details, scam signals, a TrustScore, and a recommended action.
For audio scams, deBunq transcribes the voice note before risk scoring.
For document and image input, deBunq extracts payment information from invoices, screenshots, and photos of physical bills.
The confirmation flow sends the analysis result back to the backend. The backend then decides whether a bunq action can be prepared.
If the TrustScore is too low, the bunq API call is blocked server-side.
If the request is safe, the backend prepares the bunq payment or scheduled payment through the bunq sandbox API.
Multimodal input
deBunq is not limited to typed text.
A user can paste an email, upload a PDF, upload an image, upload an audio file, or take a live picture of a physical document.
This matters because scams arrive in different formats.
A forwarded voice note can carry emotional pressure. A PDF can look official. A screenshot can hide missing context. A phishing email can combine a fake sender, a short deadline, and a suspicious link.
deBunq treats the input format as part of the risk analysis.
The current prototype supports:
| Modality | Example input | What deBunq does |
|---|---|---|
| Text | Pasted phishing email or payment reminder through message text | Extracts details and scores scam risk |
| Image | Screenshot, bill photo, invoice image | Reads the document and extracts payment fields |
| Invoice, fine, tax letter, utility bill | Extracts text and payment details | |
| Audio | Suspicious voice note (Upload .m4a / .mp3 / .webm) | Transcribes the message and checks for scam signals |
All inputs are converted into the same analysis structure.
That means the TrustScore, red flags, account picker, bunq pre-flight, and receipt flow work the same way for every format.
TrustScore
The TrustScore is the core of deBunq.
Every payment request is scored from 0 to 100.
A high score means the request looks safe. A low score means the request looks suspicious.
The score is based on several trust signals:
- Issuer authenticity
- Urgency pressure
- Payment detail completeness
- Source channel risk
TrustScore
The TrustScore is the core of deBunq.
Every payment request is scored on four axes. Each axis is scored from 0 to 100. A higher score means safer.
Claude returns the sub-scores. The backend then combines them into one final TrustScore using a weighted average.
| Sub-score | Weight | What it measures |
|---|---|---|
| Issuer authenticity | 35% | Checks whether the sender, company name, domain, and IBAN are consistent with the claimed issuer. |
| Urgency pressure | 30% | Detects pressure tactics like urgent language, emotional pressure, secrecy requests, or family-emergency framing. |
| Payment-detail completeness | 20% | Checks whether the IBAN, amount, reference, and beneficiary are present and consistent. |
| Source-channel risk | 15% | Scores the input channel. An official PDF is usually safer than a screenshot, and a forwarded voice note is higher risk. |
The final risk level determines what bunq is allowed to do.
| Risk level | Rule | bunq action |
|---|---|---|
| Safe | TrustScore is 75 or higher and Claude does not flag the request. | bunq action button is enabled. |
| Caution | TrustScore is between 40 and 74. | Manual review is required. |
| Blocked | TrustScore is below 40 or is_suspicious is true. | bunq API call is refused server-side. |
This lets deBunq explain the result.
It does not only say “safe” or “unsafe”. It shows why the request was trusted or blocked.
For example, a real invoice may score high because the issuer looks consistent, the IBAN is valid, and the request has complete payment details.
A phishing email may score low because it uses urgency, a suspicious link, and a new IBAN.
A family-emergency voice note may score low because it uses emotional pressure, secrecy, and no clear payment reference.
Key features
Phishing and scam detection
deBunq checks payment requests for phishing and scam signals.
It looks for urgency, impersonation, secrecy, suspicious links, unclear beneficiaries, missing references, and changed payment details.
The goal is not only to read the request.
The goal is to decide whether it should be trusted before money leaves the account.
Voice scam detection
deBunq can analyze suspicious voice notes.
This helps detect family-emergency scams where someone pretends to be a child, parent, friend, or colleague.
The app checks the message for urgency, secrecy, emotional pressure, and payment manipulation.
Fake invoice detection
deBunq can analyze invoices and payment reminders that look legitimate.
It checks whether the payment details make sense.
It also checks whether the request contains suspicious signals, like a changed IBAN or unusual urgency.
This is useful for phishing emails and fake invoices.
Payment detail extraction
When a request is legitimate, deBunq extracts the payment fields.
It finds the amount, IBAN, beneficiary, due date, invoice number, and reference.
This removes the need to manually copy every field into a banking app which is quite slow.
It also reduces typing mistakes before a payment is created which is less error-prone.
Safe bunq action preparation
deBunq only prepares a bunq action after the risk check.
Suspicious requests are blocked.
Legitimate requests can be prepared for payment or scheduling.
The user still reviews the final step before anything happens.
bunq app integration
deBunq is designed to work as a layer inside the bunq experience.
The app connects to the bunq API and prepares account actions based on the extracted payment details.
The user can also switch between different bunq accounts with different balances.
When the user confirms a safe action, the backend sends the action to bunq from the selected account.
The account balance is then updated in the sandbox flow.
This makes the prototype feel like a real banking experience instead of a separate document scanner.
bunq-style user experience
We wanted deBunq to feel like it could live inside bunq.
The UI uses a colorful bunq-inspired theme, mobile-first screens, rounded cards, and clear action buttons.
The goal is to make scam protection feel natural inside the payment flow.
Challenges we ran into
One challenge was making the flow simple.
Payment requests contain many fields. We had to decide what to show first and what to keep in the detailed result.
Another challenge was making phishing detection useful without being too alarming.
A warning should help the user think. It should not scare them without reason.
We also had to support different input formats.
A pasted email, a PDF invoice, a photo of a bill, and a voice note all need different processing steps.
Another challenge was connecting the scam analysis to real bunq behavior.
It was not enough to hide a button in the UI. We wanted suspicious requests to be blocked server-side before any bunq API call was made.
We also had to build a realistic demo.
We needed examples that looked like real bills, real invoices, and real scam attempts.
At the same time, we wanted to avoid using private or unsafe real phishing content.
This created a trade-off.
To integrate the prototype properly with the bunq app and API, we needed payment details that could work in the sandbox flow. That included realistic IBANs, amounts, and references.
But real examples often contain private data. Scam emails can also contain unsafe links, real victims, or active mule accounts.
We chose to use controlled demo examples where needed.
Accomplishments that we are proud of
We are proud that deBunq focuses on the moment before payment.
The app does not only extract data. It helps decide whether the user should trust the request.
We are proud that suspicious requests can be blocked.
The product is not just a faster way to pay. It is a safety layer before the payment happens.
We are also proud of the multimodal flow.
deBunq can handle text, documents, images, and suspicious voice notes.
We are proud of the bunq integration.
A safe request can go from analysis to bunq pre-flight to sandbox payment.
We are also proud of the interface.
It feels close to a real banking experience. It is colorful, mobile-first, and easy to understand.
It feels like how bunq feels to us.
What we learned
We learned that phishing protection is not only a security problem.
It is also a user experience problem.
A user needs clear language, structured information, and the right warning at the right time.
We also learned that scams do not arrive in one format.
A fake invoice, a phishing email, a screenshot, and a voice note can all lead to the same result: the user sends money to the wrong place.
We learned that the input channel matters.
A voice note with emotional pressure is different from a normal invoice. A screenshot is different from an official PDF. The format itself can be a risk signal.
We also learned how important it is to design AI tools with user control.
The best experience is not full automation. The best experience is guided decision-making.
Limitations
The current version is a prototype.
The model can still miss edge cases.
Some payment requests may have unusual formats.
The Home, Budget, and Docs pages currently use demo data.
More testing is needed with realistic and anonymized examples.
The scam detection should be improved with more examples and better evaluation.
The current prototype focuses on payment scam prevention and bunq action preparation.
It is not a full replacement for bank-side fraud systems.
What is next for deBunq
Next, we want to improve the phishing and scam detection.
We want to support more scam types, including fake invoices, family-emergency voice notes, payment-link scams, and tax impersonation.
We also want to improve document support.
The app should work better with parking fines, municipal tax letters, energy bills, telecom invoices, tuition invoices, and health insurance bills.
We want to add a document vault.
Users could keep bills, fines, proof of payment, and dispute evidence in one place.
We also want to add stronger bunq integration.
The long-term goal is simple.
A user should be able to receive any payment request, drop it into deBunq, and know whether it is safe to pay.
Try it out
Upload or paste a phishing email, fake invoice, suspicious voice note, bill, fine, or payment reminder.
You can also take a picture of a physical document and upload it.
Example invoices and scam emails can be found in the data folder of our repository.
deBunq extracts the payment details, checks the TrustScore, flags scam signals, and prepares the safest next step.
Built With
- ai
- amazon-web-services
- analysis
- api
- audio
- bedrock
- built
- claude
- css
- document
- fastapi
- next.js
- python
- react
- tailwind
- transcription
- typescript
- with
Log in or sign up for Devpost to join the conversation.