Hi, I'm Terry Kieferling.
For the past 8+ years I've worked at the intersection of payments, fraud, and the product and operational decisions that follow from both.
In payments and fraud, the biggest risks are the ones teams don't know to build for yet. I turn domain knowledge into product decisions - and when incidents happen anyway, I make sure they don't happen twice.
Iād like to invite you to take a look at the proof. This portfolio contains a mix of product documents developed as personal projects/proofs of concept and case studies based on the problems I solved in my career.
<aside> š”
If you saw something you like, contact me under [email protected] or find me on linkedin: in/tkieferling For organizational purposes: Iām located in Bremen, Germany.
</aside>
Most chargeback operations start with a simple intake form and a plan to iterate later. The iteration rarely happens ā because by the time the pain is visible, the form is load-bearing infrastructure that everything else was built around. Instead, it's the operational overhead that keeps ballooning.
This case study covers the design and delivery of a dispute processing system at a European neobank, built from scratch for the company's first card product launch. The constraints were real: a fixed go-live date, a one-time organisational window unlikely to reopen, a nebulous plan to one day integrate directly with Visa and a very clear goal to never make the chargeback an operational problem.
The core decisions ā structured intake as a translation layer between cardholder experience and card network requirements, a data architecture designed to grow by activation rather than accretion, and tooling choices that traded aesthetics for foundations ā were all made with one question in mind: what needs to be right now so that everything built later doesn't have to undo it.
Includes system architecture, design rationale, and an honest account of what was delivered, what was deferred, and what was left unresolved.
Some architectural details were purposefully omitted from the case study to avoid sharing proprietary information.
Case Study: Dispute Infrastructure
<aside> š”
Projects below are pre-validation concepts I found interesting enough to think through and document properly - not documentation of shipped work. Most of my professional output is internal tooling and risk controls that aren't mine to share; these exist to show product thinking that can actually be seen.
</aside>
A pet care coordination tool built around a deliberate product philosophy: generate useful artifacts, share through channels people already use, store data where users control it.
The app targets multi-person households and rescue organizations ā anywhere care responsibility is distributed across people who may not share the same tools or tech comfort level.
Key decisions include a local-first architecture, no-install sharing for secondary users, and a print/scan loop that treats a fridge sheet as a legitimate interface.
Includes 1-pager, PRD, and wireframes.