YunLab.ai YunLab · How a Scam Works
In October 2026, I received a debt collection text. The sender correctly stated my name, national ID number and bank card number, claiming that I had an unpaid loan of CNY 140,000. The message threatened to sue me, notify my family, friends and employer, and publish my personal information if I did not deal with it. It ended with a website address and told me to contact “official customer service” there.
I had never borrowed from this platform. After checking my bank statements, I could find no incoming payment for a matching amount during the relevant period. In other words, a text written with complete certainty was demanding repayment for a claim I could find no evidence for.
What makes this kind of debt collection deceptive is the way it brings together a platform, an account, bills, a contract, a red company seal, a lawyer’s letter, customer service and a repayment page. Together, they present a complete collection process. The more complete the pages and documents look, the easier it becomes to treat an unverified claim of debt as a “fact.” This article takes the website apart to see how it builds credibility, step by step, and where to stop and question each step.
The domain in the text was 2tvvm[.]top, and the page called itself “Xiang Fen Qi” (享分期). The first anomaly I noticed when I visited was that no verification text arrived on my phone, yet a six-digit verification code appeared directly on the webpage.
Step 1: Knowing Your Details Does Not Mean You Owe Money
A common first line of defense against a collection text is: “They got my details wrong.” This message worked that instinct in reverse. The more accurate the information, the easier it was to believe what followed. With my name, ID number and bank card number all matching, the claim that “you owe money” appeared to have a basis.
But these are two different things. The sender having my information establishes only that they have that information; its source has not been determined. There must be corresponding borrowing, signing and disbursement records to connect “knowing who I am” with “I owe money.” Any materials the other party provides need to be verified. They alone are not a reason to accept the debt. Verification should take place through official bank or financial institution channels that I find independently, checking the source of the materials and whether the signing records and incoming payments correspond.
Step 2: Being Able to Log In and See Bills Does Not Mean You Borrowed Money
This review of the public code showed that the login component reads a six-digit web_code returned by the site’s own API, puts it directly into a popup and offers to fill it in automatically. The page states plainly: “The code is displayed on this page; it does not verify ownership of the phone number.” This login flow therefore includes a branch in which the website delivers the code straight to the current page. Logging in does not depend on receiving a code on a phone. That matches what I observed at the time. In this branch, the check is not about who has the phone, but whether the page lets you through.
The limits of that finding matter too. It establishes only that this flow does not verify ownership of the phone number. It does not establish that the platform has no SMS service at all, or that there is no genuine business behind it. One thing is clear, however: at this point, all I have seen is the “account” the website chooses to show me.
My earlier records show that, after login, the page displayed a CNY 140,000 loan and CNY 175,280 outstanding. It also refused account deletion on the grounds that 12 bills remained unpaid. The webpage obtains these figures from the site’s own API. Without access to the backend, I cannot tell whether the data is stored in a database, generated by the API on demand, or assembled from hard-coded values. On the interface, the company name, application name, logo, customer service avatar and even the seal image are configurable. The same code can present a different brand simply by changing the configuration. The page scripts also map several older components to the current code, showing a structure that allows modules to be reused and components to be replaced. The materials do not establish who developed this code, what it cost, or how many websites have used it. Those clues cannot answer those questions.
A browser interface, API fields and templates can assemble something that looks like a complete platform. But a “complete interface” establishes only that the interface is complete. It does not establish a genuine financial business behind it, let alone prove that I registered or borrowed money.
Step 3: A Contract, a Red Seal and a Lawyer’s Letter—Apparently Three Pieces of Evidence, but One Source
Documents make the debt look more real. A contract, a red seal and a lawyer’s letter each appeal to a different assumption: the contract suggests “I signed this,” the seal suggests “an institution stands behind it,” and the lawyer’s letter suggests “legal proceedings are coming.” The more complete the formal presentation, the easier it becomes to mistake “all the documents are here” for “the underlying facts are real.”
The current code shows that the contract component calls the website’s own loan, member, identity document and configuration APIs, then fills a template with the name, ID details, phone number, bank card details and amount. The “Borrower’s signature” field simply displays a name variable. “Download contract” actually invokes the browser’s print function. In the component examined, no signing confirmation, handwriting capture or signature verification flow was found. A contract that looks signed can, in fact, be assembled by the webpage.
The seal uses a configured image when one is available. The seal image field is empty in the current public configuration, and the code provides a fallback: the webpage draws a red circle, a star, and the company name and a number arranged around the circle. That fallback number combines the loan date with seven random digits. It is separate from the contract number, which comes from the API’s order number. This review did not retest whether a particular account could obtain a seal image from another response.
The lawyer’s letter likewise comes from component and template rules. If there is no valid principal amount, it defaults to CNY 33,000. If the date is missing or incorrectly formatted, it defaults to February 1, 2025. The due date is calculated by adding 21 days to the loan date, even though an information table on the same page states 12 installments. Interest and penalties are not calculated entry by entry from an interest rate; they follow fixed, hard-coded calculation rules. These rules explain how a formally complete letter can be produced. They do not mean that every number I saw on the page used a default value. The lawyers, companies and institutions named in the letter were not verified in this review, so their actual involvement cannot be inferred.
Here is the point: these three items appear independent, but their data comes from this website’s own APIs, and they are generated by their respective components and templates. Their agreement shows only that the website is internally consistent. It adds no independent evidence of borrowing or receipt of funds. Verification must concern real-world signing and disbursement, rather than materials the website issues and displays itself.
Step 4: Threats and “You Cannot Delete Your Account” Push Verification Aside
The threats in the text—legal action, notifying family, friends and an employer, and publishing personal information—may make someone eager to end the trouble, skip verification and deal directly with the “debt.” The page then blocks an apparent exit with “the account cannot be deleted until the debt is cleared.” It becomes easy for the question to shift from “Did I ever borrow this money?” to “How do I get this dealt with first?” Once the question shifts, verification gets pushed back.
The customer service entry point on the website specified in the text takes over from there. The original message only told me to contact customer service through this website; the particular way the connection is made is not fixed. The current customer service component has a mechanism worth noticing: as you type, it submits the draft text and typing status through a separate API. The page says, “Your input is provided to customer service for a live preview; it becomes a chat message only after you click Send.” Each character is not submitted separately; updates are scheduled and combined. But after three seconds without typing, the current draft is still submitted along with the stopped-typing status. Text that has not been sent therefore does not necessarily remain only on my device. The code does not reveal whether the server keeps older drafts. The implication is straightforward: the other side may already be seeing words you have not yet decided to send.
Step 5: Two Exits—Money and More Personal Information
Payment channels are configurable. The repayment page can display bank card, Alipay or WeChat account details or QR codes. When the channel list is empty, the page says that no payment method is available and directs the user to customer service. The main flow presented by the page is to pay outside the website, then upload a screenshot as proof and wait for the website to review it.
Two things need to be kept separate here: making an external payment and having the website review its proof are different steps. The proof enters the website’s own process. “The website confirms receipt” proves neither that the original debt exists nor who the actual recipient is. This section describes how the interface guides someone toward paying and submitting proof. It does not say that such a transfer happened to me.
Alongside payment, the other exit is more personal information. The forms are set up to collect a name, ID number, photos of the front and back of an ID card, a photo holding the ID card, bank card details and the phone number registered with the bank. They also ask for marital status, home address, employer, job title, work phone number, income, work address and emergency contacts. The interface thus has two kinds of requests ready: money and more personal information. If someone follows the page’s instructions to submit information or make a payment, this review has not established the recipient’s identity or where the information or funds go afterward.
Where to Stop at Each Step
Look at the chain as a whole. Accurate details make someone believe “they have the right person.” The web account turns “the right person” into “you owe money.” The contract, red seal and lawyer’s letter make one website’s claims look as though several documents support one another. Threats create pressure to settle the matter quickly. The designated customer service entry point takes over the conversation. Payment and proof-submission steps guide the person toward paying, while forms collect more information. Each part seems unremarkable on its own; together, they form a complete machine. Its underlying logic can be put in one sentence: first get you to accept an unverified debt as the premise of the discussion, then build a series of demands around that premise.
Understanding that logic shows what to watch for when a website appears under a different name or design: the debt has not been independently verified, yet the other party uses accurate personal details, documents within its own site and threats to press for payment or more information first. Accounts, contracts, customer service and repayment pages are not, by themselves, grounds for identifying a scam.
The response is to pause at each step. Do not accept a debt just because the other party gets your personal information right. Do not pay or provide more information simply to end the threats. Check borrowing records and receipt of funds only through official bank or financial institution channels you find independently, rather than using the links or customer service contacts supplied in the text as your verification channel. I also do not recommend that anyone log into this website to investigate. Keep the original texts, timestamps, webpage records and transaction records, and seek advice, file a complaint or contact the police when needed. The 96110 service provides scam-prevention intervention, advice and reporting; if you discover you have been scammed, preserve the evidence and promptly call 110. The Nanjing Municipal Public Security Bureau’s explanation Complaints about spam texts, scam calls, harmful websites and personal information leaks can be submitted to 12321. 12321’s scope One further point needs to be clear: an article cannot stop the spread of personal information that has already leaked, and nobody can promise that “do this and you will never be scammed again.” What we can do is pause each time before paying or handing over more information.
Scope: This article draws on my earlier records and an offline review of public code on October 26, 2026. No account was logged into again for verification in this round. It explains mechanisms supported by the website’s frontend. Who operates the backend, how the personal information was obtained and where any funds go remain unresolved. The materials contain no verified record of a payment, formal police acceptance of a report or a judicial finding.
Production note: Kimi Code performed the earlier analysis of this website. Codex assisted with this round of public-code review and corrections. The manuscript was generated through Ji Yanran’s (纪嫣然) writing workflow, with Codex assisting in the review and correction of a small number of factual statements. It is recorded at YunLab under the name Yun.Z. English translation: Codex publication translator.
Sources: