<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Toden]]></title><description><![CDATA[Toden]]></description><link>https://todenhq.hashnode.dev</link><image><url>https://cdn.hashnode.com/uploads/logos/6adb4c6a5ae06650eaeec612/9423f4e3-b6a7-41da-b373-0784fe6e4b72.png</url><title>Toden</title><link>https://todenhq.hashnode.dev</link></image><generator>RSS for Node</generator><lastBuildDate>Sun, 25 Oct 2026 10:33:20 GMT</lastBuildDate><atom:link href="https://todenhq.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[We built a fintech. Then we built Toden.]]></title><description><![CDATA[By Charles Archibong, co-founder of Toden. This is our account of why we built it. Building a fintech makes you think carefully about the person on the…]]></description><link>https://todenhq.hashnode.dev/we-built-a-fintech-then-we-built-toden</link><guid isPermaLink="true">https://todenhq.hashnode.dev/we-built-a-fintech-then-we-built-toden</guid><dc:creator><![CDATA[Toden]]></dc:creator><pubDate>Fri, 23 Oct 2026 14:41:56 GMT</pubDate><content:encoded><![CDATA[<p><em>By Charles Archibong, co-founder of Toden. This is our account of why we built it.</em></p>
<p>Building a fintech makes you think carefully about the person on the other side of the screen. Someone wants to open an account, move money or run a business. They have a reason for being there. You want to help them get on with it.</p>
<p>You also have a responsibility to know who they are, understand the risks and protect the service they are trusting you to run.</p>
<p>We felt both responsibilities while building our fintech. We wanted to make something people could rely on. Along the way, we ran into a problem that became the starting point for <a href="https://toden.co">Toden</a>: fragmented verification, fraud and compliance tools.</p>
<h2>The work between the checks</h2>
<p>There are good tools for checking an identity document. There are tools for verifying a business, screening a name and assessing fraud risk. A team still has to connect those checks to a customer's journey and decide what happens next.</p>
<p>Who needs to review an uncertain result? What information should that person see? How does their decision reach the application? What should happen when another signal arrives after onboarding?</p>
<p>These questions sit between engineering, operations and compliance. Each check may have an answer, while the team still needs a complete picture of the customer.</p>
<p>Our experience made us pay attention to those connections. A successful API response is one step in a much longer responsibility.</p>
<h2>Keeping the person in view</h2>
<p>It is easy to talk about onboarding as a conversion funnel. For the person trying to use a financial product, it is a moment of trust.</p>
<p>They have shared something personal. They may have photographed a document, taken a selfie or supplied information about their business. The next screen should help them understand where they stand and what they need to do.</p>
<p>The people operating the service need that clarity too. A reviewer should be able to understand why a case needs attention. A developer needs to know which result is final and which work is still pending. A compliance team needs a record it can follow.</p>
<p>Those are the kinds of questions we wanted to design around. We care about the person waiting for an answer and the team responsible for giving one.</p>
<h2>Why we built Toden</h2>
<p>We built Toden to connect customer verification and the work that follows it.</p>
<p>Teams can verify people and businesses, screen sanctions and watchlists, assess risk, monitor activity, and investigate alerts through an API and dashboard. Configurable workflows connect the steps. SDKs and hosted links provide ways to collect information, and signed webhooks bring results back to an application.</p>
<p>The aim is to give teams a connected record they can use from onboarding through ongoing review. The business still owns its policies and decisions. Software should make those decisions easier to understand and carry out.</p>
<p>We also wanted developers to have room to test. Toden has a free sandbox, with pay-per-check production pricing. Teams can explore the <a href="https://toden.co/developers">developer resources</a> before deciding whether it fits their product.</p>
<h2>What we would ask before another integration</h2>
<p>Our experience changed the questions we ask when evaluating these tools:</p>
<ul>
<li>Can we follow one customer across verification, review and later activity?</li>
<li>Can a reviewer see the evidence and understand why a case needs attention?</li>
<li>What happens when a result is delayed, a request is retried or a person needs to step in?</li>
<li>Can we test those situations before customers depend on the integration?</li>
<li>Can we explain the next step clearly to the customer?</li>
</ul>
<p>Those questions are useful whether a team chooses Toden or another approach. They help turn a collection of checks into a process people can operate with care.</p>
<h2>Building for the teams doing the work</h2>
<p>Toden grew out of the experience of building a fintech and wanting the tools around it to fit together better.</p>
<p>We know how much care goes into a financial product. The interface people see rests on decisions, checks and responsibilities they may never see. We want to help the teams carrying that responsibility build with greater clarity.</p>
<p>That is the work ahead of us. We are sharing what we build and listening to the people connecting these systems in their own products.</p>
<p>If fragmented verification, fraud and compliance tools are part of your working day, we would like to hear which connection causes you the most difficulty.</p>
<p>Explore <a href="https://toden.co">Toden</a>, or reach the team at <a href="mailto:hello@toden.co">hello@toden.co</a>.</p>
]]></content:encoded></item><item><title><![CDATA[Introducing Toden: a checklist for connecting verification and ongoing monitoring]]></title><description><![CDATA[A practical checklist for customer verification flows, signed webhooks, retries, manual review and ongoing monitoring, with an introduction to Toden.]]></description><link>https://todenhq.hashnode.dev/introducing-toden-a-checklist-for-connecting-verification-and-ongoing-monitoring</link><guid isPermaLink="true">https://todenhq.hashnode.dev/introducing-toden-a-checklist-for-connecting-verification-and-ongoing-monitoring</guid><category><![CDATA[api integration]]></category><category><![CDATA[Security]]></category><dc:creator><![CDATA[Toden]]></dc:creator><pubDate>Fri, 23 Oct 2026 12:11:09 GMT</pubDate><enclosure url="https://cdn.hashnode.com/uploads/covers/6adb4c6a5ae06650eaeec612/6e28c0e0-b646-4421-b643-baae5d4b22d1.png" length="0" type="image/jpeg"/><content:encoded><![CDATA[<p>Customer verification is more than a collection screen. An integration also needs a way to receive results, handle retries, route cases for review and keep track of what happens after onboarding.</p>
<p>We built <a href="https://toden.co">Toden</a> to bring customer verification, business verification, sanctions screening and fraud monitoring into one API and dashboard. Here is a practical checklist for teams connecting those parts of an onboarding flow. These are integration design considerations, not Toden API endpoint or status definitions.</p>
<h2>1. Separate collection from the decision</h2>
<p>Treat “the customer has submitted their information” and “the checks have produced a result” as separate events. Your interface should make it clear when the customer has finished their part and when a result is still pending.</p>
<p>Before writing the happy path, decide how your application will display pending checks, requests for more information and cases that need a person to review them. Map the provider’s documented result states to your own product states explicitly.</p>
<h2>2. Choose the collection experience first</h2>
<p>Decide where the verification journey belongs in your product. Consider an embedded experience, an SDK or a hosted link in light of the devices and channels your customers use. The surrounding application still needs to preserve the right customer reference and show a clear next step when collection ends.</p>
<p>Toden supports SDKs and hosted links alongside its API, so teams can evaluate the collection approach separately from their internal review process.</p>
<h2>3. Make event handling safe to retry</h2>
<p>For any webhook integration, establish the documented method for checking authenticity before trusting a result. Then design your handler so receiving the same event again does not repeat a business action.</p>
<p>Use a stable reference to connect the event to the right internal record. Record what was processed, and test delayed delivery, retries and duplicate notifications. Keep transport acknowledgement separate from work that can run asynchronously. Use the provider’s documentation for the exact signature, retry and event semantics; do not infer them from the shape of a sample payload.</p>
<p>Toden provides signed webhooks. The application consuming them still owns its own state updates and business actions.</p>
<h2>4. Plan the review path alongside the API path</h2>
<p>A person reviewing a case needs enough context to understand what happened and decide the next step. Define which team owns the review, what information it needs and how the outcome returns to the application.</p>
<p>Toden’s dashboard supports configurable workflows, investigations and reporting. Those tools should fit the process your team has defined, rather than leaving the review path as an afterthought.</p>
<h2>5. Test what happens after onboarding</h2>
<p>Initial verification and ongoing monitoring solve different parts of the workflow. Identify which later events should trigger attention, how cases are assigned and how your application will reflect subsequent changes.</p>
<p>Test those paths before production, including interrupted collection, delayed results and manual review. Toden includes a free sandbox for integration testing; production uses pay-per-check pricing with no monthly minimum or contract.</p>
<h2>Explore Toden</h2>
<p>You can learn more at <a href="https://toden.co">toden.co</a> and find us on <a href="https://github.com/todenhq">GitHub</a>, <a href="https://x.com/todenhq">X</a> and <a href="https://www.linkedin.com/company/todenhq/">LinkedIn</a>.</p>
<p>We welcome feedback from developers connecting verification, screening and ongoing monitoring. Which handoff creates the most integration work in your current setup?</p>
]]></content:encoded></item></channel></rss>