Synapse, an payment and KYC/AML API-provider recently introduced they are trialing with real-time payment (RTP). This would be an tremendous improvement to what most Head of Finance or consumers who conduct ACH and/or wires know as of today – which is a multi-day ACH/wire settlement time. I really enjoy like what this startup is doing in the payment space so I embarked on a mini journey of going through their API developer docs and monthly/bimonthly developer log.

BEST TAKEAWAY from this specific development log:

July – August Release Notes

1. “RTP will work with existing ACH-US nodes where RTP will be an option available for banks that support RTP.”
   
   This RTP feature will allow the company to build Plaid-like stickiness whereby, having contracts with each individual or group of banks will allow their API to develop strong competitive advantage, one that takes more than $ and time to chip away.
   
2. “Soft Descriptor functionality enables you to dynamically modify the statement descriptor on a per-transaction basis.”
   
   This soft descriptor modification feature is likely to get around the credit/debit card transaction protocol dominance of VISA/Mastercard. I remembered reading about how Square had to navigate around how these duopoly’s description protocol that in essence, forces companies to play by their credit card transaction descriptor rules.
   
   If a consumer swipe their credit/debit card on a Square point-of-sale (POS) back then, VISA/Mastercard will populate “SQ-transaction” on the consumer’s bank statement and not show who the actual vendor is – which subsequently, elevated the risks of fraud transaction reporting by consumers and thereby, more COGS expenses (fraud refund transaction cost) and OpEx (hire more customer support team members) for the company Square’s general product philosophy back in its early days was “make the product and pricing so easy and simple that they don’t need to hire any customer support staff until they transaction $xx million+ in gross merchandise value (GMV) transactions per month.
   
3. “KYC/AML ID Score V2”
   
   As a reminder, our governance module can be used to automate workflows based on the user’s ID Scores (and now trust_level) so a customer with a higher ID Score submits less KYC while a customer with a lower ID Score submits more. ID Score is a probabilistic score (0-1) assigned to all users at the time of onboarding that predicts the likelihood that the identity supplied belongs to the person who is creating the account. 1 means we are 100% certain that the user is who they say they are. 0% means with 100% certainty we can say that the user is not who they say they are.
   
   It seems like the probability calculation for this might be somewhat abstract? For example, how how many limited scenarios and limited data KYC/AML historical and/or current customer data points can the system analyze to come up with a probability? I think the application and value-add for this is incremental tremendous given this is pseudo credit score-like system for customer KYC/AML with different risk profile, and ultimately, will shorten the # of steps and costs (unit economics given how KYC/AML is done these days in modular pricing structure).