# Michele Durante's blog > Notes on payments, fintech and software engineering. Each page is also on the site at its URL without `.md`. The RSS feed is at https://blog.micheledurante.com/feed.xml. © 2026 Michele Durante. All rights reserved. --- Source: https://blog.micheledurante.com/index.md # Michele Durante Notes on payments, fintech and software engineering. ## [Economies and diseconomies of scale in code: what economists know about DRY](https://blog.micheledurante.com/economies-and-diseconomies-of-scale-in-code.md) **11 October 2026** What economies of scale, and where they end, say about DRY: sharing code pays up to a point, and economics tells you where that point is. ## [A valid payment can still go to the wrong person: an exercise in fencing in an AI agent](https://blog.micheledurante.com/a-valid-payment-can-still-go-to-the-wrong-person.md) **8 October 2026** Sketching an AI agent that repairs rejected payments: it can be built, but most of the work sits around the agent, not in it. ## [The junior work we think we're saving](https://blog.micheledurante.com/the-junior-work-we-think-were-saving.md) **30 September 2026** Handing the junior work to AI saves less than it seems. What I took from Christian Catalini's essay on the economics of AI: producing work is getting cheap, checking it is not, and that moves where the value is. --- Source: https://blog.micheledurante.com/about-me.md # About me I'm Michele Durante, Team Lead Payments at [RaiseNow](https://raisenow.com), a payment processor and acquirer for fundraising and donation. I lead a frontend and a backend payment team there, and I'm based in Munich. I have worked as a developer for more than ten years, nearly ten of them in payments: ATM transaction processing at Euronet in Munich, eCommerce websites and payment providers at Nowtel in London, and now payment processing and acquiring at RaiseNow. For eight of those years I have led teams. Along the way I have worked on PCI-DSS compliance and audits, and turned legacy systems into modular, tested ones with automated releases. After ten years of building payment systems, I'm now studying the business behind them: how money is created, how schemes, acquirers and payment infrastructure fit together, and the regulation that shapes them, through CFTE's [*Payments in Digital Finance*](https://courses.cfte.education/payments-in-digital-finance-specialisation-2/) course. I want to work where engineering, product and the payments business meet, and to be as useful to compliance, partner and finance teams as I am to developers. This blog is where I write up what I learn (see [Now learning](https://blog.micheledurante.com/now-learning.md)). My [CV](https://blog.micheledurante.com/cv.md) has the details. You can also find me on [LinkedIn](https://uk.linkedin.com/in/michele-durante-b743992a/en) and [GitHub](https://github.com/micheledurante). --- Source: https://blog.micheledurante.com/cv.md PDF: [michele-durante-cv.en.pdf](https://blog.micheledurante.com/michele-durante-cv.en.pdf) · [michele-durante-cv.it.pdf](https://blog.micheledurante.com/michele-durante-cv.it.pdf) # Michele Durante ## Team Lead Payments at RaiseNow | Payment Processing & Acquiring | Cloud-Native Engineering | Compliance & PCI-DSS ### Personal Details

Full Name: Michele Durante
Location: München, Deutschland

Nationality: Italian

Email: me@micheledurante.com

GitHub

Xing

### About Payments engineering leader with 10+ years of experience, including nearly 10 years in the payment industry and 8 years in leadership roles. I have a proven track record of building, scaling, and leading engineering teams to improve delivery quality and operational efficiency. I design adaptable solutions for fast-changing requirements across cloud and on-prem environments, with strong focus on reliability, documentation, and business interoperability. I also integrate AI-assisted development practices, agentic workflows, and AI-powered developer tooling to accelerate delivery, improve engineering productivity, and support high-quality outcomes. Currently, I work at Raisenow, where I lead payment frontend and backend teams building and maintaining a FinTech SaaS platform for fundraising and donation. I am extending my payments expertise from engineering to the business and regulatory side, currently through CFTE's Payments in Digital Finance course (money creation, card schemes and payment infrastructure, PSD2, CBDCs). With hands-on experience across the payment chain, from ATM transaction processing to acquiring, I bridge engineering with product, compliance and partner teams.

Frontend/Backend Technologies

DevOps Technologies

PHP, .NET, TypeScript and JavaScript, Java, several e2e and unit testing frameworks, REST, GraphQL, SPA, Git, MySQL, MS SQL, and Oracle.

Linux administration, on-prem and cloud (AWS, Azure), several CI/CD systems, distributed & event-driven systems, Docker, Ansible, OpenShift, microservices, observability principles, AI-assisted software development, AI agents & agentic workflows, AI-powered developer tooling.

Career History

Team Lead Payments
RaiseNow
Nov. 2024 - present

Digital Payments SaaS, 100% remote, Germany
RaiseNow is a payment processor and acquirer for fundraising and donation. I lead a frontend and a backend payment team, consult on technical aspects and work on designing and delivering payment solutions.

I helped design, specify, and implement acquiring and payment processing capabilities.
I contributed to compliance efforts and PCI-DSS certification work, helping the organisation meet the standards of the payments industry.
I led frontend and backend teams in building and maintaining an event-driven, cloud-native SaaS platform.
I improved the platform's scalability, reliability, and security by introducing the best development and management practices.
As hiring manager, I interviewed candidates for engineering roles and onboarded new team members.
I collaborated with product, design, and GTM teams to deliver high-quality software that meets customer needs and business goals.

Team Lead
Euronet
Nov. 2018 - Oct. 2024

Electronic Payments and Financial Services, Munich, Germany
ATM transaction processing. Team size of 6-8 members, part of a team 24-large. I spent most of my time on designing software and/or systems, coaching developers and testers, discussing specifications. The rest was dedicated to hands-on coding, tasks reviews and, when needed, to hiring. I coordinated communication with distributed teams across timezones and released software globally.

I developed and maintained mission-critical production code and internal applications.
I defined long-term goals for the development team, sharing responsibility for hiring, onboarding, best practices, and Sprint planning.
I was responsible for internal and external security audits and compliance with PCI-DSS and PA-DSS standards.
I designed, implemented, and maintained automated test suites covering unit, integration, and end-to-end scenarios, optimising them for cloud and on-premise deployments.

Full-stack Developer
Euronet
Nov. 2017 - Oct. 2018

Electronic Payments and Financial Services, Munich, Germany
ATM transaction processing. I replaced much of the legacy codebases and set up modern processes for testing and for the release of software

I modernised outdated monolith APIs and web applications (.NET, PHP) into modular solutions.
I designed and implemented CI/CD systems and test suites for unit and integration testing (Java).
I optimised requirements gathering and product/development processes.

Full-stack Developer & PM
Nowtel
Nov. 2015 - Oct. 2017

Mobile Virtual Network Operator (telecommunication), London, UK
Development of customer-facing websites and APIs for a telecommunication company. I was responsible for the eCommerce websites and related payment services. Finally, I also managed a project with an external design agency to redesign and launch the new websites.

I refactored and maintained legacy systems (Java, PHP), worked on data modelling and new web applications in .NET, and implemented several payment providers and payment methods.
I analyzed and integrated payment gateways, third-party APIs, website internationalisation, UI/UX design, and customer experience, ensuring consistency across devices and media while working closely with marketing.

Web Developer & PM
Freelancer
Jan. 2013 - Sept. 2015

Business partnership, London, UK
I worked on several projects for startups and small business in London, working together a graphic designer as a business partner under the name Studio Durante.

Junior Web Developer
University of the Arts, London
Sept. 2012 - Jul. 2013

Student/Intern, London, UK
I gained professional experience whilst studying by working on a contract-basis for the University. I joined the in-house development team and shadowed a senior developer working on online and distance teaching/learning platforms.

Education & Courses

Sept. 2010 - Jul. 2013

UAL, London, UK
Digital Media, Computer Science, BA
Digital media & Design, Multimedia installations, C/C++ programming, PHP programming, Web design, Web development

Dec. 2016

C# Online course (Udemy)
CSharp programming language, Inheritance, Object-Oriented programming, Access modifiers, Interfaces, MVC5, .NET Framework.

Sept. 2026 - present

Payments in Digital Finance, CFTE (online course, in progress)
Money creation and money supply, public and private money, payment networks and infrastructure, card schemes, PSD2, digital currencies and CBDCs, payment instruments and processing.

Awards

Jun. 2013 Art Temps, Employee of the year Award Nominee

Nov. 2011 JISC, University of the Arts London. ALTO digital Competition. Winner of the 1st Commended Prize

Languages

Italian Native proficiency

English Native or bilingual proficiency (IELTS 8.5 British Council)

German Basic proficiency (B1.1 Goethe Institute)

--- Source: https://blog.micheledurante.com/now-learning.md # Now learning As of October 2026, I've finished [**Payments in Digital Finance**](https://courses.cfte.education/payments-in-digital-finance-specialisation-2/), an online course by CFTE (the Centre for Finance, Technology and Entrepreneurship), which I started in September. It came in two parts. The first was on money: how it is created, public and private money, card schemes and payment infrastructure, and digital currencies such as CBDCs. The second was on payments themselves: the risks of payment accounts and networks, PSD2, fast payments and overlay services, clearing systems and card switches, how payment operations are run, from processing cycles to straight-through processing, and the economics of payments. I write up what I learn as entries on this blog. --- Source: https://blog.micheledurante.com/economies-and-diseconomies-of-scale-in-code.md # Economies and diseconomies of scale in code: what economists know about DRY Published **11 October 2026** ## TL;DR - Shared code is a fixed cost spread over its uses: it pays only once there are enough of them, and the rule of three is a rough guess at that break-even point. - Past a certain size, every user of a shared abstraction pays for the needs of all the others, and that coupling cost can outgrow the savings. - Keeping a duplicate on purpose is an option, not a failure: it leaves you free to abstract later, once you know what the copies really share. "Don't repeat yourself" is one of the first rules we learn as developers, and one of the most satisfying to apply: spot two similar blocks, pull them into a shared function, delete a dozen lines (very satisfying :D). Most of what I read about DRY celebrates those savings. Far less of it asks when sharing stops paying. I have a personal reason to ask. For my side projects I keep a small private TypeScript library, `deno-tools`, with a rule that goes with it: when a project needs something the library could hold, extend the library, never copy its code. Building this blog meant four changes to that library in a single day before the blog would build, and it made me wonder whether my rule is a good deal. Economics turned out to have the words for it and, more usefully, a way to tell where the deal ends. The whole mapping at a glance, with the details below: | Economics | Programming | What it adds | | --- | --- | --- | | Economies of scale: a fixed cost spread over output | Writing a shared function once; each new use is cheap | The basic analogy | | Minimum efficient scale | The rule of three: abstract only at the third copy | Abstraction has a break-even point, and you can estimate it | | Diseconomies of scale (coordination, bureaucracy) | Shared code that has to serve every user, so each change ripples to all of them | Past a certain size, sharing costs more than it saves | | Lock-in and switching costs | Being tied to an abstraction that is hard to change | The hidden long-term cost | | Economies of scope: shared inputs across *different* products | One library used by unrelated projects | A closer fit for DRY than scale | | Coase: make or buy, and the cost of each transaction | Write it, depend on a library, or copy it | Explains when *not* to share | | Real options | Keeping a duplicate on purpose, to abstract later | A reason to wait that is easy to defend | ## Economies of scale: a fixed cost spread over its uses A shared function is a fixed cost: you pay once to write, test and document it, and each new use is nearly free. My library's `fetch` is a good example: a drop-in replacement that retries failed requests, written once, and for any project that needs it the whole cost is one import. ```ts import { fetch } from "./deno-tools/src/http/fetch.ts" // Retries network errors and failed responses, five attempts by default const res = await fetch("https://api.example.com/rates") ``` Spreading a fixed cost only works with enough output to spread it over. Written as a rule, sharing pays when the expected reuses × the saving per reuse is greater than the cost of building the abstraction plus the coupling cost it puts on each user. None of these can be measured precisely, but writing them down already changes the question from "is this duplicated?" to "will this be used enough to pay back?". ## Minimum efficient scale: the rule of three Economists call the smallest output at which average cost stops falling the minimum efficient scale. Programming has a rough estimate of it: the rule of three, popularised by Martin Fowler's *Refactoring*: the first time, write it; the second time, wince and copy it; the third time, abstract. Two copies don't tell you what is really shared and what only looks alike. Payments have a neat example: ```ts // Two copies look alike: amounts in cents, two decimals const euros = (cents: number) => `${(cents / 100).toFixed(2)} EUR` const francs = (cents: number) => `${(cents / 100).toFixed(2)} CHF` // The third shows what varies: the yen has no minor unit const format = (amount: number, currency: string, decimals: number) => `${(amount / 10 ** decimals).toFixed(decimals)} ${currency}` ``` Abstract at two copies and you hard-code the two decimals, then undo it the day the yen arrives. ## Diseconomies of scale: when sharing gets too big Firms run into diseconomies of scale: past some size, coordination and bureaucracy cost more than size saves. Shared code runs into the same thing: every user of a shared function pays for the needs of all the others, and changing it means checking every one of them. Sandi Metz put it in one line in [The Wrong Abstraction](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction): "duplication is far cheaper than the wrong abstraction". My library had a small case of it. Its site builder worked out where each page goes by replacing `src` in the page's path with the output folder. That held as long as every site kept its sources in a folder named `src`, which they all did, until this blog needed a staging folder of its own: ```ts // Before: correct only while the source folder is called "src" const out = path.replace(/\bsrc\b/g, outputDir) // After: the page's path under the source folder, whatever its name const out = join(outputDir, relative(sourceDir, path)) ``` The fix itself was one line. The cost was everything around it: tests, docs, a changelog entry, and, sooner or later, a library update in every project that builds a site, whether it needed the change or not. Lock-in is the long-term form of the same cost: the more projects lean on an abstraction, the harder it gets to change. ## Economies of scope: different projects, shared parts Most of the value in my library isn't scale at all. Economies of scope are savings from sharing inputs across *different* products, which is closer to what it does: Telegram bots, an API, a command-line assistant and a few websites have little in common, but they share logging, that retrying `fetch` and a static site build. The Markdown renderer was written for this blog and now also builds my study notes. Ronald Coase asked why firms make some things and buy others; every dependency is the same choice between writing it, depending on it or copying it, and the answer depends on what integrating it costs. ## Real options: keeping the copy on purpose A real option is the right, but not the duty, to act later. Keeping a duplicate on purpose buys one: you can still abstract once a third case shows what is shared, whereas an abstraction made too early has to be undone first, which costs more than the copy ever did. ```ts // Copied from the bot on purpose: the two may still drift apart. // Share it when a third project needs it. const backoff = (attempt: number) => Math.min(1000 * 2 ** attempt, 30_000) ``` ## The numbers so far Since March 2025, eight of my projects have come to use the library, which holds about a dozen modules, and those projects have updated their copy of it 52 times. The costs are easy to count: those updates, and that day of fixes for the blog. The savings are code I never had to write, which is harder to count. My honest answer is that the rule pays for the parts every project uses, logging and builds, and I would not extend it to code only one project needs. ## Read next - [A valid payment can still go to the wrong person: an exercise in fencing in an AI agent](https://blog.micheledurante.com/a-valid-payment-can-still-go-to-the-wrong-person.md), 8 October 2026 ## About the author I'm Michele Durante, Team Lead Payments at RaiseNow. I write here about what I learn in payments and fintech, and the engineering around them. Read more [about me](https://blog.micheledurante.com/about-me.md), see my [CV](https://blog.micheledurante.com/cv.md), or follow new entries by [RSS](https://blog.micheledurante.com/feed.xml). --- Source: https://blog.micheledurante.com/a-valid-payment-can-still-go-to-the-wrong-person.md # A valid payment can still go to the wrong person: an exercise in fencing in an AI agent Published **8 October 2026** ## TL;DR - Fixed rules settle every reject they can, and the agent only gets what is left; repairs that people approve every time move back into rules. - The line is drawn by field, not by trust: the agent may change how something is written, never who gets how much, and a check outside the agent enforces it. - Quality is measured after the fact, failures feed tests and rules rather than the agent, and people stay able to check it, because the bank answers for every repair. I lead payment teams, and the most tempting pitch for AI agents in banking I've come across is also the simplest: payments get rejected all day, people fix them by hand, so let an agent fix them. It sounds like the perfect first job for an agent, as nobody loves the exception queue (I certainly don't :D). I came across a report from a CFTE roundtable on how banks move from copilots, which help a person, to agents, which act on their own. Rather than stay abstract, I tried to design one agent end to end: one that repairs rejected payments. My conclusion is that it can be built, but it does much less than "repairs rejected payments" suggests, and most of the work sits around it rather than in it. ## Why rejects are a good place to start A reject is the earliest kind of R-transaction: a bank refuses a payment instruction before settlement because it cannot process it, say a wrong format or an invalid account number. No money has moved yet. That makes it the safest point in a payment's life to let an agent act, because a mistake can still be caught before it costs anything. ## Rules first, the agent for the rest Many rejects already have a fixed answer, and ISO 20022 gives each one a standard reason code. Account closed? Don't retry, send it back. Insufficient funds? Don't retry either. These need a rules engine, which is cheaper, testable and explainable, not an agent. The agent earns its place only with what a fixed rule cannot handle: free text in the wrong field, a date written in a local format, that kind of mess. And when people approve the same repair every time, it leaves the agent and becomes a rule, or the client sending those files is asked to fix them at the source. The agent's job should shrink over time, not grow. ```mermaid flowchart LR R[Rejected payment] --> K{Known reason code?} K -->|yes| F[Fixed rule] K -->|no| A[Agent proposes a repair] A --> V{Checks outside the agent} V -->|passes| S[Resubmitted] V -.->|fails| H[Operations team] ``` Only the dotted line reaches a person: repairs that fail the checks. ## A valid message can still be wrong This is the part that changed how I think about it. A validator checks the form of a message, not its meaning. An IBAN with a typo fails its check digits, and an agent could "fix" it by changing a digit until the check passes. The result is a perfectly valid IBAN that belongs to someone else, and the payment goes to the wrong person with no error anywhere. So the boundary is not "how much do we trust the agent", it's which fields it may touch. It may change how something is written (character sets, date formats, code values) and never who pays whom or how much: payer, payee, account, amount and currency are off limits. A separate check compares the repaired message with the original and rejects any change to those fields, so the rule holds whatever the agent does. ## Measuring the right thing The obvious metric is the share of repairs that pass validation. It's also the wrong one. A repair that passes and comes back days later as a return or a recall is a failure that no success rate shows. The real measures are what happens to repaired payments afterwards, and the near misses: every time the field check stops the agent from touching a protected field, nothing went wrong, so nothing would be counted, yet it's the agent trying exactly the shortcut of the valid but wrong IBAN. Those failures are the most valuable data the bank has, as I wrote in [The junior work we think we're saving](https://blog.micheledurante.com/the-junior-work-we-think-were-saving.md). Here they feed a fixed set of test cases and new rules, never the agent itself: no failures as examples in its prompt and no training on them, otherwise the tests only measure what it memorised. ## The people behind it If only the hard cases reach people, the operations team loses the routine work it used to learn on, and a few years later fewer people can check the agent. Two practices help: a small blind sample, where someone repairs a reject before seeing the agent's proposal, and a few planted wrong proposals in the queue. If people overrule the agent less often, either it got better or they stopped looking, and the planted ones tell the two apart. ## Who stands behind a repair Whatever the agent does, the bank answers for it: to its customer when a payment goes wrong, and to the regulator when a repair hides a sanctions match. Buying the model from a vendor doesn't move that responsibility. So the agent belongs to the head of the operations team whose queue it takes over, and its business case has to count the cost of checking it (the exception queue, the samples, the returns) next to the hours it saves. Count only the hours, and you get the savings now and the costs later, somewhere else. ## What I take away The interesting design work isn't in the agent. It's in the rules that keep its job small, the check that fences it in, the metrics that look past validation, and the people who stay able to say no. An agent that does less, inside walls it doesn't control, is one a bank can actually stand behind. ## Read next - [The junior work we think we're saving](https://blog.micheledurante.com/the-junior-work-we-think-were-saving.md), 30 September 2026 - [Economies and diseconomies of scale in code: what economists know about DRY](https://blog.micheledurante.com/economies-and-diseconomies-of-scale-in-code.md), 11 October 2026 ## About the author I'm Michele Durante, Team Lead Payments at RaiseNow. I write here about what I learn in payments and fintech, and the engineering around them. Read more [about me](https://blog.micheledurante.com/about-me.md), see my [CV](https://blog.micheledurante.com/cv.md), or follow new entries by [RSS](https://blog.micheledurante.com/feed.xml). --- Source: https://blog.micheledurante.com/the-junior-work-we-think-were-saving.md # The junior work we think we're saving Published **30 September 2026** ## TL;DR - AI makes producing work cheap, but checking it still moves at human speed, and the gap between the two is where both the risk and the value now sit. - The data worth keeping is no longer the finished work but the record of what failed, was rejected or nearly went wrong. - As output gets cheap, value moves to whoever can stand behind a result and pay when it is wrong. I lead payment teams and, among other things, act as hiring manager. Since many people in companies started using AI, I've heard several iterations of the same idea: AI takes over the junior work and we save money. We all instinctively have an intuition of its fallacy (or at least I hope we do :D), but it's tempting to ignore it given the quick returns. Christian Catalini's essay [The Economics of AI](https://catalini.com/ideas/economics-of-ai/) gave me the words for that intuition. It sums up "Some Simple Economics of AGI", a working paper he wrote with Xiang Hui and Jane Wu, and despite the title it's about how AI is already moving the value in everyday work, not about machines becoming generally intelligent one day. ## Execution at machine speed, verification at human speed The core idea is simple: producing work is becoming almost free, checking it isn't. An agent can write a specification, the code and a launch campaign overnight. Lovely, until someone has to find out whether it invented a fact, opened a security hole or took a clever shortcut around its goal. Production runs at machine speed. Checking runs at human speed, or at the speed of the real world when the answer only arrives years later. Catalini calls the widening distance between the two the Measurability Gap. ## Why we take the risk anyway So why not slow down wherever checking is hard? Because for the company that doesn't, the maths works. The savings arrive now and land on the company, while the cost of a hidden failure arrives later and often lands on someone else: customers, or the wider market. Skipping the checks is a rational choice for one company, even when it's a bad deal for everyone. The cost that worries me most is the slowest one, and it brings me back to that idea about juniors. Experts learn their judgement through years of routine work, so if agents take over the junior work, in ten years there are fewer people able to supervise the agents. As someone who hires engineers, I keep asking myself: if juniors no longer do the work, how do they learn to check it? The essay's answer is to rebuild the apprenticeship on purpose, with simulations in which people decide before they see the answer. ## The data worth keeping Most companies treat their archive of finished work as the treasure, but finished work only teaches a model what to produce, and models see more of it every year. The data worth keeping is the record of what to reject and why: blocked deployments, near misses, postmortems, expert overrides. This one felt very familiar from payments, where moving money is the easy bit and the real knowledge sits in the exceptions, the disputes and the chargebacks. A competitor can copy a workflow, but not the years of cases that taught you when to trust it. ## A second model is not a second opinion AI will have to help check AI, as there is simply too much output for people to read. The catch is that a checker built on similar data and design shares the blind spots of the model it checks. People make independent mistakes, which is useful; agents built on the same foundations can make the same mistake a million times and politely approve each other's work. Real verification needs different methods, real-world outcomes and a person who stays responsible for the result. ## Who stands behind it I'll admit liability was the thread I was slowest to see (it turns out it runs through the whole essay). If anyone can produce a polished result, the customer stops caring which model made it and starts caring who guarantees it. In high-stakes markets the essay expects AI firms to be judged more like insurers than like software vendors, which favours banks and insurers, with their licences and balance sheets. The policy argument follows: as long as failures cost someone else, companies buy too little verification. Make the deployer pay, and verification tools get built without anyone prescribing how AI must be designed. ## When more users make a network worse The idea I liked most connects to what I'm [studying](https://blog.micheledurante.com/now-learning.md). Card schemes are the textbook two-sided market: more cardholders attract more merchants, and the other way round. That network effect quietly assumes every participant is real. Agents can fill a marketplace with listings and reviews, and because they make the same mistakes, more activity can make a network less trustworthy rather than more useful. The network effect runs in reverse. ```mermaid flowchart LR A[More agent activity] ==>|the same plausible mistakes| T[Less trust] T ==>|the best contributors leave| V[A less valuable network] ``` What counts then is how much participation people can trust, and a platform's history of resolved fraud cases, disputes and chargebacks becomes its real advantage. ## What I take away None of this is an argument against using AI: the essay's goal is "the maximum automation you can verify, insure, reverse, and still understand". So, back to the junior work and the money we save. For engineering teams, the saving is real only if we count the work we can stand behind rather than the work produced, keep the record of what we rejected and why, and give juniors a way to learn to check work they no longer write. ## Read next - [A valid payment can still go to the wrong person: an exercise in fencing in an AI agent](https://blog.micheledurante.com/a-valid-payment-can-still-go-to-the-wrong-person.md), 8 October 2026 ## About the author I'm Michele Durante, Team Lead Payments at RaiseNow. I write here about what I learn in payments and fintech, and the engineering around them. Read more [about me](https://blog.micheledurante.com/about-me.md), see my [CV](https://blog.micheledurante.com/cv.md), or follow new entries by [RSS](https://blog.micheledurante.com/feed.xml).