Skip to main content

Slash that...Google wallet wasn't the problem.



Update (Friday April 3, 2015) !!

It turns out I wrote this article on the wrong information. Google it turns out is not to blame for the delay the authorizing bank is the source. For what ever reason they flagged the transaction for review (likely the fact that the investor was in Europe when she initiated the request) and that is why the fund transfer to her Google Wallet account and to mine has been delayed. I thus retract the bulk of the comments made below with the mistaken belief that the hold was an internal matter on Google's part. Still the fact that their customer service were unable to clearly specify the source of the block is a big issue that they should address the integrity of their system for review is not relevant as it was not their system that was the cause of this issue. I keep this article up only  as public record of the affair.


So the month starts anew and with it I receive a transfer from my investor at least I am supposed to via Google wallet as initiated by her action…usually this process happens instantly but not this time.

The transaction remained in a permanent state of “pending” for most of the morning and then not wanting to play the role of a nag I asked my investor if she could call Google and check to see what the issue was. This is *after* I called them and confirmed that the issue was not due to a block placed on my account.
She called Google and was told that the reason it was blocked was due to a *random* flag for review that their automated security service engages.

This makes sense and is normal for many banks to provide but what stuck out was the use of the world “random” which my investor confirmed was stated by the rep. It should be clear to any one that having a random review process would make no sense…as it provides a non zero probability that one flags for review a transaction that is completely 100% on board, the optimal process for flagging should apply some type of filter to the criteria of transactions in order to trigger a flag….for example it turns out that my investor is in Europe at the moment and though she has transferred funds from outside of the nation before, that *may* be a consideration in a security flagging heuristic (many banks employ them to ensure fraud is not happening).

However the transaction was not flagged due to any consideration other than a random one which is a failure of the business process, it simply should not work this way…it’s bad design.
Things get more convoluted, apparently the items flagged for review on this random schedule hijack the funds for up to 9 days of review.

Considering that many of these transfers involve fulfillment of contract payments between vendors and customers this is *unacceptable* for any running business to tolerate. Yes, Google indicates that this is possible up front in their terms of service but it is STILL unacceptable as it undermines the very action that many people are using the service for that it was PRIMARILY designed to engage.

Their TOS is akin to having a car manufacturer telling you in the purchase contract that the car they just sold you is likely to lose wheels in mid transit down the road and that the car company is absolved of responsibility …this is absurd and any law that enables such madness is a flawed one (looking at you USG). That said from a business perspective having your funds delayed up to 9 days is just the start of the issues….the funds are in a limbo where neither the SENDER or the RECEIVER has access to them.
How do I know Google isn't making money off of that money in the churn gap (they likely are but aren't paying either of us jack squat for it).

This stinks to high heaven….it is beyond EVIL which Google has expressed is their charter, “don’t be evil” …well Google you have fucking failed on an epic level with this rule.

So what can Google do to aleviate themselves of this evil practice they are currently engaging in??
Well the delay for review is almost certainly due to the fact that what ever automated system they have performing the “random” flags is populating some common queue of transactions and those are then fed to live human agents who then are tasked with making sure that the transaction is valid and not fraudulent…this takes time…however it is very easy for google to set the rate at which such flags are performed (since they are as they say “random”) so as events fill the queue the review team knows the rate at which they are clearing the incidents and for what ever reason set a 9 day max limit on time to review from first entry to system…as I mentioned earlier this is *unacceptable* as users rely on the transactions happening as soon as possible….1 day would be potentially troublesome , 9 days is absolutely absurd.

A single days delay could mean the difference between an on time payment and a late fee assessed for being one day beyond. A single days delay could mean that an account goes into collections….Google has every responsibility to get this done inside a 24 hour cycle…so they can:
HIRE MORE REVIEWERS

If they hire more reviewers then they can shorten the maximum wait time from delays they can arbitrarily hire the numbers required to get the review time down below a day…and solve this problem.
If they reduce the rate at which the random selection is happening they can solve the problem as well.

 As mentioned earlier there is NO reason why the flagging is “random” in the first place that is a flaw that needs to be removed from the system…but beyond that reducing the selection rate would reduce the review rate for customers and that can get it below 24 hours wait.
If they stop random selection entirely and only trigger reviews for transactions that have unique signatures (like a request that comes from a foreign country when a previous history of request were not) they reduce the load of flagged items in the queue and again reduce the time to review.

All of these things can be done by Google NOW to alleviate themselves of these *unacceptable* delays incurred on their users for a service that promises the opposite of what they are delivering when they hold funds hostage for more than one day.

I am hoping some one at Google gets this and puts plans into motion to fix this major flaw in their service. I otherwise enjoy Google Wallet it has replaced a good deal of my banking and I’d love to provide additional advice on how it can be even better but the first is to actually make the service work as people are expecting any banking service to work….anything else is:
unacceptable.
The other side of the coin…
So the customer service side of things was some what reasonable…save for the fact that they could not expedite the solution to the problem.
If it is the case that items from a given day need to be cleared by a given day in the future (up to 9 days in current flawed system) then it means that unless a user calls up to COMPLAIN when they get their money can fall any where in that 9 days…
however
If I am a pissed off customer and I need that transaction to go through ASAP and I take time out of my busy day to call your customer service to express the fact that I need that review expedited then it should be done …
without delay
without excuse
it should be done.
After all the queue of items for a given day is already KNOWN (if it is not known then there is another FLAW in the system design that needs fixing) and it is on this basis that the 9 day guarantee can even be made (think about it) so to then tell me that you can’t reorder my transaction for execution before others who are oblivious and accepting of the delay is basically absolute bullshit.
So when my investor called Google Wallet and told them she needed the transfer to go over they gave her some nonsense about it being still considered for early review….which is again unacceptable. This should not be a decision that any one is reviewing….at this point the users money is in limbo some quantum mechanical state of alive and dead that neither the SENDER of the money nor the RECIEVER can access…how this entire situation is even legal is beyond me….but it is definitely Evil , it is definitely non Google and it definitely needs to be fixed NOW.
If Google needs technical help figuring it out I am a software engineer, I’ve build very complex systems and I can help guide the process give me a ring…or email…or text. I just want my money.
Let me know when you stop being evil in this regard Google and I’ll update this article with new information.

Comments

Dom Saint-loth said…
I second this post! Give David the entrepeneur his funds pronto or you will be placed on double secret probation.

Popular posts from this blog

On the idea of "world wide mush" resulting from "open" development models

A recent article posted in the Wall Street Journal posits that the collectivization of various types of goods or services created by the internet is long term a damaging trend for human societies.

http://online.wsj.com/article/SB10001424052748703481004574646402192953052.html

I think that the author misses truths that have been in place that show that collectivization is not a process that started with the internet but has been with us since we started inventing things.

It seems that Mr. Lanier is not properly defining the contexts under which different problems can benefit or suffer from collectivization. He speaks in general terms of the loss of the potential for creators to extract profit from their work but misses that this is and was true of human civilization since we first picked up a rock to use as a crude hammer. New things make old things obsolete and people MUST adapt to what is displaced (be it a former human performance of that task or use of an older product) so as to main…

Highly targeted Cpg vaccine immunotherapy for a range of cancer

Significance?


This will surely go down as a seminal advance in cancer therapy. It reads like magic:

So this new approach looks for the specific proteins that are associated with a given tumors resistance to attack by the body's T cells, it then adjusts those T cells to be hyper sensitive to the specific oncogenic proteins targeted. These cells become essentially The Terminator​ T cells in the specific tumor AND have the multiplied effect of traveling along the immune pathway of spreading that the cancer many have metastasized. This is huge squared because it means you can essentially use targeting one tumor to identify and eliminate distal tumors that you many not even realize exist.

This allows the therapy for treating cancer to, for the first time; end the "wack a mole" problem that has frustrated traditional shot gun methods of treatment involving radiation and chemotherapy ...which by their nature unfortunately damage parts of the body that are not cancer laden but …

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…